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NATIONAL FOREWORD 



This Indian Standard (Part 2) (First Revision) which is identical with ISO/IEC 15408-2 : 2005 'Information 
technology — Security techniques — Evaluation criteria for IT security — Part 2 : Security functional 
requirements' issued by the International Organization for Standardization (ISO) and International 
Electrotechnical Commission (lEC) jointly was adopted by the Bureau of Indian Standards on the 
recommendations of the Information Systems Security Sectional Committee and approval of the Electronics 
and Information Technology Division Council. 

This standard was originally published in 2001 and was identical with ISO/IEC 15408-2 : 1999 and has now 
been revised to align it with the latest ISO/IEC Publication. 

The text of the ISO/IEC Standard has been approved as suitable for publication as an Indian Standard without 
deviations. Certain conventions are, however, not identical to those used in Indian Standards. Attention is 
particularly drawn to the following: 

a) Wherever the words 'International Standard' appear referring to this standard, they should be read 
as 'Indian Standard'. 

b) Comma (,) has been used as a decimal marker while in Indian Standards, the current practice is to 
use a point (.) as the decimal marker. 
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Indian Standard 

INFORMATION TECHNOLOGY — 

SECURITY TECHNIQUES — EVALUATION 

CRITERIA FOR IT SECURITY 

PART 2 SECURITY FUNCTIONAL REQUIREMENTS 

, ^ ( First Revision) 

1 Scopo 

This part of ISO/IEC 15408 defines the required structure and content of security functional components for 
the purpose of security evaluation. It includes a catalogue of functional components that will meet the common 
security functionality requirements of many IT products and systems. 

2 Normative references 

The following referenced documents are Indispensable for the application of tt>is document. For dated 
references, only the edition cited applies. For undated references, the latest edition of the referenced 
document (including any amendments) applies. 

ISO/IEC 15408-1, Information technology — Security techniques —- Evaluation criteria for IT security — 
Part 1: Introduction and general model 

3 Terms, definitions, symbols and abbreviated terms 

For the purposes of this document, the terms, definitions, symbols and abbreviated terms given in 
ISO/IEC 15408-1 apply. 

4 Overview 

ISO/IEC 15408 and the associated security functional requirements described herein are not meant to be a 
definitive answer to all the problems of IT security. Rather, ISO/IEC 15408 offers a set of well understood 
security functional requirements that can be used to create trusted products or systems reflecting the needs of 
the market. These security functional requirements are presented as the cun-ent state of the art in 
requirements specification and evaluation. 

This part of ISO/IEC 15408 does not presume to include all possible security functional requirements but 
rather contains those that are known and agreed to be of value by this part of ISO/IEC 15408 authors at the 
time of release. 

Since the understanding and needs of consumers may change, the functional requirements In this part of 
ISO/IEC t5408 will need to be maintained. It is envisioned that some PP/ST authors may have security needs 
not (yet) covered by the functional requirement components in this part of ISO/IEC 15408. In those cases the 
PP/ST author may choose to consider using functional requirements not taken from ISO/IEC 15408 (referred 
to as extensibility), as explained in annexes A and B of ISO/IEC 15408-1. 

4.1 Organisation of this part of ISO/IEC 15408 

Clause 5 describes the paradigm used in the security functional requirements of this part of ISO/IEC 15408. 

Clause 6 introduces the catalogue of this part of ISO/IEC 15408 functional components while clauses 7 
through 17 describe the functional classes. 
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Annex A provides explanatory information for potential users of the functional components including a 
complete cross reference table of the functional component dependencies. 

Annex B through Annex M provide the explanatory information for the functional classes. This material must 
be seen as normative instructions on ^ow to apply relevant operations and select appropriate audit or 
documentation information; the use of the auxiliary verb should means that the instruction is strongly preferred, 
but others may be justifiable. Where different options are given, the choice is left to the PP/ST author. 

Those who author PPs or STs should refer to clause 2 of ISO/lEC 15408-1 for relevant structures rules and 
guidance: 

a) ISO/lEC 15408-1 , clause 2 defines the terms used in ISO/lEC 15408. 

b) tSO/lEC 15408-1 , annex A defines the structure for PPs. 

c) iSO/lEC 1 5408-1 , annex B defines the structure for STs. 

d) ISO/lEC 15408-1 , annex C contains a bibliography of relevant reference documents. 

5 Functional requirements paradigm 

This clause describes the paradigm used in the security functional requirements of this part of ISO/lEC 15408. 
Figures 1 and 2 depict some of the key concepts of the paradigm. This subclause provides descriptive text for 
those figures and for other key concepts not depicted. Key concepts discussed are highlighted in bold/italics. 
This subclause is not intended to replace or supersede any of the temis found in ISO/lEC 15408-1, clause 2. 




,'niote 
l^rndiirt 




Target of 1- valuation (TOE) 



TOI: Security Functions Interface (TSFI) 




Figure 1 - Security functional requirements paradigm (IMonolithic TOE) 

This part of ISO/lEC 15408 is a catalogue of security functional requirements that can be specified for a 
Target of Evaluation (TOE). A TOE is an IT product or system (along with user and administrator guidance 
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documentation) containing resources such as electronic storage media (e.g. disks), peript>eral devices {e.g. 
printers), and computing capacity (e.g. CPU time) that can be used for processing and storing information and 
is the subject of an evaluation. 

TOE evaluation is concerned primarily with ensuring that a defined TOE Security Policy (TSP) is enforced 
over the TOE resources. The TSP defines the rules by which the TOE governs access to its resources, and 
thus all information and services controlled by the TOE. 

The TSP is, in turn, made up of multifile Security Function Policies (SFPs). Each SFP has a scope of 
control, that defines the subjects, objects, and operations controlled under the SFP. The SFP is implemented 
by a Security Function (SF), whose mechanisms enforce the policy and provide necessary capabilities. 
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Figure 2 - Diagram of security functions in a distributed TOE 



Those portions of ^ TOE that must be relied on for the correct enforcement of the TSP are collectively referred 
to as the TOE Security Functions (TSF). The TSF consists of all hardware, software, and fimiware of a TOE 
that is either directly or indirectly relied upon for security enforcement. 

A reference monitor is an abstract machine that enforces the access control policies of a TOE. A reference 
validation meclianism is an implementation of the reference monitor concept that possesses the following 
properties: tamperproof, always invoked, and simple enough to be subjected to thorough analysis and testing. 
The TSF may consist of a reference validation mechanism and/or other security functions necessary for the 
operation of the TOE. 



The TOE may be a monolithic product containing hardware, firmware, and software. 
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Alternatively a TOE may be a distributed product that consists internally of multiple separated parts. Each of 
these parts of the TOE provides a particular service for the TOE, and is connected to the other parts of the 
TOE through an internal communication channel. This channel can be as small as a processor bus, or may 
encompass a network internal to the TOE. 

When the TOE consists of multiple parts, each part of the TOE may have its own part of the TSF which 
exchanges user and TSF data over internal communication channels with other parts of the TSF. This 
interaction is called internal TOE transfer. In this case the separate parts of the TSF abstractly form the 
composite TSF, which enforces the TSP. 

TOE interfaces may be localised to the particular TOE, or they may allow interaction with other IT products 
over external communication channels. These external interactions with other IT products may take two 
forms; 

a) The security policy of the "remote trusted IT product" and the TSP of the local TOEs have been 
administratively coordinated and evaluated. Exchanges of information in this situation are called inter- 
TSF transfers, as they are between the TSFs of distinct trusted products. 

b) The remote IT product may not be evaluated, indicated in Figure 2 as "untrusted IT product", therefore its 
security policy is unknown. Exchanges of information in this situation are called transfers outside TSF 
control, as there is no TSF (or its policy characteristics are unknown) on the remote IT product. 

The set of interactions that can occur with or within a TOE and are subject to the rules of the TSP is called the 
TSF Scope of Control (TSC). The TSC encompasses a defined set of interactions based on subjects, objects, 
and operations within the TOE, but it need not encompass alt resources of a TOE. 

The set of interfaces, whether interactive (man-machine interface) or programmatic (application programming 
interface), through which resources are accessed that are mediated by the TSF, or information is obtained 
from the TSF, is referred to as the TSF Interface (TSFI). The TSFI defines the boundaries of the TOE 
functions that provide for the enforcement of the TSP. 

Users are outside of the TOE, and therefore outside of the TSC. However, in order to request that services be 
performed by the TOE, users interact with the TOE through thB TSFI. There are two types of users of interest 
to this part of ISO/IEC 15408 security functional requirements: human users and external IT entitles. Human 
users are further differentiated as local human users, meaning they interact directly with the TOE via TOE 
devices (e.g. workstations), or remote human users, meaning they interact indirectly with the TOE through 
another IT product. 

A period of interaction between users and thre TSF is referred to as a user session. Establishment of user 
sessions can be controlled based on a variety of considerations, forexample: user authentication, time of day, 
method of accessing the TOE, and number of allowed concurrent sessions per user. 

This part of ISO/IEC 15408 uses the term authorised to signify a user who possesses the rights and/or 
privileges necessary to perform an operation. The term authorised user, therefore, indicates that it is 
allowable for a user to perform an operation as defined by the TSP. 

To express requirements that call for the separation of administrator duties, the relevant this part of ISO/IEC 
15408 security functional components (from family FMT_SMR) explicitly state that administrative roles are 
required. A role is a pre-defined set of rules establishing the allowed interactions between a user and the TOE. 
A TOE may support the definition of any number of roles. For example, roles related to the secure operation of 
a TOE may include "Audit Administrator" and "User Accounts Administrator". 

TOEs contain resources that may be used for the processing and storing of information. The primary goal of 
the TSF Ts the complete and correct enforcement of the TSP over the resources and information that the TOE 
controls. 

TOE resources can be structured and utilised in many different ways. However, this part of ISO/IEC 15408 
makes a specific distinction that allows for the specification of desired security properties. All entities that can 
be created from resources can be characterised in one of two ways. The entities may be active, meaning that 
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they are the cause of actions that occur internal to the TOE and cause operations to be performed on 
information. Alternatively, the entities may be passive, meaning that they are either the container from which 
Information originates or to which information is stored. 

Active entities are referred to as subjects. Several types of subjects may exist within a TOE: 

a) those acting on behalf of an authorised user and which are subject to all the rules of the TSP (e.g. UNIX 
processes); 

b) those acting as a specific functional process that may in turn act on behalf of multiple users (e.g. 
functions as might be found in client/server architectures;); or 

c) those acting as part of the TOE itself (e.g. trusted processes). 

this part of ISO/IEC 15408 addresses the enforcement of the TSP over types of subjects as those listed above. 

Passive entities (i.e. information containers) are referred to in this part of ISO/IEC 15408 security functional 
requirements as objects. Objects are the targets of operations that may be performed by subjects. In the case 
where a subject (an active entity) is the target of an operation (e.g. interprocess communication), a subject 
may also be acted on as an object. 

Objects can contain information. This concept is required to specify information flow control policies as 
addressed in the FDP class. 

Users, subjects, information and objects possess certain attributes that contain information that allows the 
TOE to behave correctly. Some attributes, such as file names, may be intended to be informational (i.e. to 
increase the user-friendliness of the TOE) while others, such as access control information, may exist 
specifically for the enforcement of the TSP. These latter attributes are generally referred to as "security 
attributes". The word attribute will be used as a shorthand in this part of ISO/IEC 15408 for the word "security 
attribute", unless otherwise indicated. However, no matter what the intended purpose of the attribute 
information, it may be necessary to have controls on attributes as dictated by the TSP. 

Data in a TOE is categorised as either user data or TSF data. Figure 3 depicts this relationship. User Data is 
information stored in TOE resources that can be operated upon by users in accordance with the TSP and 
upon which the TSF places no specilal meaning. For example, the contents of an electronic mail message is 
user data. TSF Data is information used by the TSF in making TSP decisions. TSF Data may be influenced by 
users if allowed by the TSP. Security attributes, authentication data and access control fist entries are 
examples of TSF data. 

There are several SFPs that apply to data protection such as access control SFPs and information flow 
control SFPs. The mechanisms that implement access control SFPs base their policy decisions on attributes 
of the subjects, objects and operations within the scope of control. These attributes are used in the set of rules 
that govern operations that subjects may perform on objects. 

The mechanisms that implement information flow control SFPs base their policy decisions on the attributes of 
the subjects and information within the scope of control and the set of rules that govern the operations by 
subjects on information. The attributes of the information, which may be associated with the attributes of the 
container (or may not, as in the case of a multi-level database) stay with the information as it moves. 
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Figure 3 - Relationship between user data and TSF data 

Two specific types of TSF data addressed by this part of ISO/IEC 15408 can be, but are not necessarily, the 
same. These are authentication data and secrets. 

Authentication data is used to verify the claimed identity of a user requesting services from a TOE. The most 
common fonn of authentication data is the password, which depends on being kept secret in order to be an 
effective security mechanism. However, not all forms of authentication data need to be kept secret. Biometric 
authentication devices (e.g. fingerprint readers, retinal scanners) do not rely on the fact that the data is kept 
secret, but rather that the data is something that only one user possesses and that cannot be forged. 

The term secrets, as used in this part of ISO/IEC 15408 functional requirements, while applicable to 
authentication data, is intended to also be applicable to other types of data that must be kept secret in order to 
enforce a specific SFP. For example, a trusted channel mechanism that relies on cryptography to preserve the 
confidenttality of information being transmitted via the channel can only be«s strong as the method used to 
keep the cryptographic keys secret from unauthorised disclosure. 

Therefore, some, but not all, authentication data needs to be kept secret and some, but not all, secrets are 
used as authentication data. Figure 4 shows this relationship between secrets and authentication data, in the 
Figure the types of data typically encountered in the authentication data and the secrets subclauses are 
indicated. 
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Figure 4 - Relationship between "authentication data" and "secrets" 



6 Security functional components 

6.1 Overview 

This clause defines the content and presentation of the functional requirements of ISO/IEC t5408, and 
provides guidance on the organisation of the requirements for new components to be included In an ST. The 
functional requirements are expressed in classes, families, and components. 
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6.1.1 Class structure 



Figure 5 illustrates the functional class structure in diagrammatic form. Each functional class includes a class 
name, class introduction, and one or more functional families. 
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Figure 5 - Functional class structure 



6.1.1.1 Class name 

The class name subclause provides information necessary to identify and categorise a functional class. Every 
functional class has a unique name. The categorical information consists of a short name of three characters. 
The short name of the class is used in the specification of the short names of the families of that class. 

6.1.1.2 Class introduction 

The class introduction expresses the common intent or approach of those families to satisfy security 
objectives. The definition of functional classes does not reflect any formal taxonomy in the specification of the 
requirements. 

The class introduction provides a figure describing the families in this class and the hierarchy of the 
components in each family, as explained in subclause 6.2. 

6.1.2 Family structure 

Figure 6 illustrates the functional family structure in diagrammatic form. 
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Figure 6 - Functional family structure 



6.1.2.1 Family name 

The family name subclause provides categorical and descriptive information necessary to identify and 
categorise a functional family. Every functional family has a unique name. The categorical infbnnation consists 
of a short name of seven characters, with the first three identical to the short name of the class followed by an 
underscore and the short name of the family as follows XXX_YYY. The unique short form of thefemily name 
provides the principal reference name for the components. 

6.1 .2.2 Family behaviour 

The family behaviour is the narrative description of the functional family stating its security objective and a 
general description of the functional requirements. These are described in greater detail below: 

a) The security objectives of the family address a security problem that may be solved with the help of a 
TOE that incorporates a component of this family; 

b) The description of the functional requirements summarises all the requirements that are included in the 
component(s). The description is aimed at authors of PPs, STs and functional packages who wish to 
assess whether the family is relevant to their specific requirements. 

6.1.2.3 Component levelling 

Functional families contain one or more components, any one of which can be selected for inclusion in PPs, 
STs and functional packages. The goal of this subclause is to provide information to users in selecting an 
appropriate functional component once the family has been identified asiieing a necessary or useful part of 
their security requirements. 

This subclause of the functional family description describes the components available, and their rationale. 
The exact details of the components are contained within each component. 

The relationships between components within a functional family may or may not be hierarchical. A 
component is hierarchical to another if it offers more security. 

As explained in 6.2 the descriptions of the families provide a graphical overview of the hierarchy of the 
components in a family. 
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6.1 .2.4 Management 



The management requirements contain information for tlie PP/ST authors to consider as management 
activities for a given component. The management requirements are detailed in components of the 
management class (FMT). 

A PP/ST author may select the indicated management requirements or may include other management 
requirements not listed. As such the information should be considered informative. 

6.1.2.5 Audit 

The audit requirements contain auditable events for the PP/ST authors to select, if requirements from the 
class FAU: Security audit, are included in the PP/ST. These requirements include security relevant events in 
terms of the various levels of detail supported by the components of the Security audit data generation 
(FAU_GEN) family. For example, an audit note might include actions that are in terms of: Minimal - successful 
use of the security mechanism; Basic - any use of the security mechanism as well as relevant information 
regarding the security attributes involved; Detailed - any configuration changes made to the mechanism, 
including the actual configuration values before and after the change. 

It should be observed that the categorisation of auditable events is hierarchical. For example, when Basic 
Audit Generation is desired, all auditable events identified as being both Minimal and Basic should be included 
in the PP/ST through the use of the appropriate assignment operation, except when the higher level event 
simply provides more detail than the lower level event. When Detailed Audit Generation is desired, all 
identified auditable events (Minimal, Basic and Detailed) should be included in the PP/ST. 

In the class FAU: Security audit the rules governing the audit are explained in more detail. 

6.1 .3 Component structure 

Figure 7 illustrates the functional component structure. 
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6.1.3.1 Component identification 



The component identification subclause provides descriptive information necessary to identify, categorise, 
register and cross-reference a component. Tlie following is provided as part of every functional component: 

A unique name. The name reflects the purpose of the component. 

A short name. A unique short form of the functional component name. This short name serves as the principal 
reference name for the categorisation, registration and cross-referencing of the component. This short name 
reflects the class and family to which the component belongs and the component number within the family. 

A hierarchical-to list. A list of other components that this component is hierarchical to and for which this 
component can be used to satisfy dependencies to the listed components. 

6.1.3.2 Functional elements 

A set of elements is provided for each component. Each element is individually defined and is self-contained. 

A functional element is a security functional requirement that if further divided would not yield a meaningful 
evaluation result. It is the smallest .security functional requirement identified and recognised in ISO/IEC 15408. 

When building packages, PPs and/or STs, it is not permitted to select only one or more elements from a 
component. The complete set of elements of a component must be selected for inclusion in a PP, ST or 
package. 

A unique short form of the functional element name is provided. For example the requirement name 
FDPJFF.4.2 reads as follows: F - functional requirement, DP - class "User data protection", JFF - family 
"Information flow control functions", .4 - 4th component named "Partial elimination of illicit information 
flows", .2 - 2nd element of the component. 

6.1.3.3 Dependencies 

Dependencies among functional components arise when a component is not self sufficient and relies upon the 
functionality of, or interaction with, another component for its own proper functioning. 

Each functional component provides a complete list of dependencies to other functional and assurance 
components. Some components may list "No dependencies". The components depended upon may in turn 
have dependencies on other components. The list provided in the components will be the direct dependencies. 
That is only references to the functional requirements that are required for this requirement to perform its job 
properly. The indirect dependencies, that is the dependencies that result from the depended upon 
components can be found in Annex A of this part of ISO/IEC 15408. It is noted that in some cases the 
dependency is optional in that a number of functional requirements are provided, where each one of them 
would be sufficient to satisfy the dependency (see for example FDP_UtT.1 Data exchange integrity). 

The dependency list identifies the minimum functional or assurance components needed to satisfy the security 
requirements associated with an identified component. Components that are hierarchical to the identified 
component may also be used to satisfy the dependency. 

The dependencies indicated in this part of ISO/IEC 15408 are normative. They must be satisfied within a 
PP/ST. In specific situations the indicated dependencies might not be applicable. The PP/ST author, by 
providing the rationale why it is not applicable, may leave the depended upon component out of the packaae 
PPorST. r f K y . 

6.2 CoiYiponent catalogue 

« 

The grouping of the components in this part of ISO/IEC 15408 does not reflect any formal taxonomy. 

This part of ISO/IEC 15408 contains classes of families and components, which are rough groupings on the 
basis of related function or purpose, presented in alphabetic order. At the start of each class is an informative 
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diagram that indicates the taxonomy of each class, indicating the families in each class and the components in 
each family. The diagram is a useful indicator of the hierarchical relationship that may exist between 
components. 

In the description of the functional components, a subclause identifies the dependencies between the 
component and any other components. 

In each class a figure describing the family hierarchy similar to Figure 8, is provided. In Figure 8 the first family, 
Family 1 , contains three hierarchical components, where component 2 and component 3 can both be used to 
satisfy dependencies on component 1. Component 3 is hierarchical to component 2 and can also be used to 
satisfy dependencies on component 2. 



Class Name 



Family 1 



Family 2 



Family 3 




Figure 8 - Sample class decomposition diagram 

In Family 2 there are three components not all of which are hierarchical. Components 1 and 2 are hierarchical 
to no other components. Component 3 is hierarchical to component 2, and can be used to satisfy 
dependencies on component 2, but not to satisfy dependencies on component 1. 

In Family 3, components 2, 3, and 4 are hierarchical to component 1. Components 2 and 3 are both 
hierarchical to component 1 , but non-comparable. Component 4 is hierarchical to both component 2 and 
component 3. 

These diagrams are me^nt to complement the text of the families and make identification of the relationships 
easier. They do not replace the "Hierarchical to:" note in each component that is the mandatory claim of 
hierarchy for each component. 

6.2.1 Component changes highlighting 

The relationship between components within a family is highlighted using a holding convention. This holding 
convention calls for the bolding of all new requirements. For hierarchical components, requirements are 
bolded when they are enhanced or modified beyond the requirements of the previous component. In addition, 
any new or enhanced permitted operations beyond the previous component are also highlighted using bold 
type. 



7 Class FAU: Security audit 

Security auditing involves recognising, recording, storing, and analysing information related to security 
relevant activities (i.e. activities controlled by the TSP). The resulting audit records can be examined to 
determine which security relevant activities took place and whom (which user) is responsible for them. 
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FAUARP: Seciiritj' audit automatic response 



FAU OEN: Security audit data generation 



FAU SAA: Security audit analysis 



FAU SAR: Security audit review 



FAU SEL: Security audit event selection 



FAUSTQ: Security audit event storage 



I 2 

3 4 



Figure 9 - FAU: Security audit class decomposition 

7.1 Security audit automatic response {FAU_ARP) 

7.1.1 Family Behaviour 

This family defines the response to be taken in case of detected events indicative of a potential securitv 
violation. ' 

7.1.2 Component levelling 



FAUARP: Security audit automatic response 



Figure 10 - FAU_ARP component levelling 

At FAU_ARP.1 Security alarms, the TSF shall take actions in case a potential security violation is detected. 

7.1.3 Management of FAU_ARP.1 

The following actions could be considered for the management functions in FMT: 
a) the management (addition, removal, or modification) of actions. 

7.1.4 Audit Of FAU_ARP.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included In the 

a) Minimal: Actions taken due to imminent security violations. 
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7.1.5 FAU_ARP.1 Security alarms 

Hierarchical to: No other components. 

Dependencies: FAU_SAA.1 Potential violation analysis 

7.1.5.1 FAU_ARP.1.1 

The TSF shall take [assignment: li^t of the least disruptive actions] upon xletection of a potential 
security violation. 

7.2 Security audit data generation (FAU_GEN) 

7.2.1 Family Behaviour 

This family defines requirements for recording the occurrence of security relevant events that take place under 
TSF control. This family identifies the level of auditing, enumerates the types of events that shall be auditable 
by the TSF, and identifies the minimum set of audit-related information that should be provided within various 
audit record types. 

7.2.2 Component levelling 



FAUOEN: Security audit data generation 



Figure 11 - FAU_GEN component levelling 

FAU_GEN.1 Audit data generation defines the level of auditable events, and specifies the list of data that shall 
be recorded in each record. 

At FAU_GEN.2 User identity association, the TSF shall associate auditable events to Individual user identities. 

7.2.3 Management of FAU_GEN.1 , FAU_GEN.2 
There are no managemfent activities foreseen. 

7.2.4 Audit of FAU_GEN.1 , FAU_GEN.2 
There are no auditable events foreseen. 

7.2.5 FAU_GEN.1 Audit data generation 
Hierarchical to: No other components. 
Dependencies: FPT_STM.1 Reliable time stamps 
7.2.5.1 FAU_GEN.1.1 

The TSF shall be able to generate an audit record of the following auditable events: 

a) Start-up and shutdown of the audit functions; 

b) All auditable events for the [selection, choose one of: minimum,basic,detaHed,not specifiedl level 
of audit; and 

c) [assignment: other specifically defined auditable events]. 
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7,2.5.2 FAU_GEN.1.2 

The TSF shall record within each audit record at least the following information: 

a) Date and time of the event, type of event, subject identity, and the outcome (success or failure) of 
the event; and 

b) For each audit event type, based on the auditable event definitions of the functional components 
included in the PP/ST, [assignment: ot/ier audit re/evanf/nformat/on]. 

7.2.6 FAU_GEN.2 User identity association 

Hierarchical to: Nq other components. 

Dependencies: FAU_GEN.1 Audit data generation 

FIA_UID. 1 Timing of identification 

7.2.6.1 FAU„GEN.2.1 

The TSF shall be able to associate each auditable event with the identity of the user that caused the 
event. 

7.3 Security audit analysis (FAU^SAA) 

7.3.1 Family Behaviour 

This family defines requirements for automated means that analyse system activity and audit data looking for 
possible or real security violations. This analysis may work in support of intrusion detection, or automatic 
response to an imminent security violation. 

The actions to be taken based on the detection can be specified using the Security audit automatic response 
(FAU„ARP) family as desired. 

7.3.2 Component levelling 



FAUS.AA: Security audit analysis 



Figure 12 - FAU_SAA component levelling 

In FAU_SAA.1 Potential violation analysis, basic threshold detection on the basis of a fixed rule set is required. 

In FAU_SAA.2 Profile based anomaly detection, the TSF maintains individual profiles of system usage, where 
a profile represents the historical patterns of usage performed by members of the profile target group. A profile 
target group refers to a group of one or more individuals (e.g. a single user, user« who share a group ID or 
group account, users who operate under an assigned role, users of an entire system or network node) who 
interact with the TSF. Each member of a profile target group is assigned an individual suspicion rating that 
represents how well that member's current activity corresponds to the established patterns of usage 
represented in the profile. This analysis can be performed at runtime or during a post-collection batch-mode 
analysis. 

In FAU_SAA.3 Simple attack heuristics, the TSF shall be able to detect the occurrence of signature events 
that represents significant threat to TSP enforcement. This search for signature events may occur in real-time 
or during a post-collection batch-mode analysis. 
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In FAU_SAA.4 Complex attack heuristics, tlie TSF shall be able to represent and detect multi-step intrusion 
scenarios. The TSF Is able to compare system events (possibly performed by multiple individuals) against 
event sequences known to represent entire intrusion scenarios. The TSF shall be able to indicate when a 
signature event or event sequence isiound that indicates a potential violation of the TSP. 

7.3.3 Management of FAU_SAA.1 

The following actions could be considered for the management functions in FMT: 

a) maintenance of the rules by (adding, modifying, deletion) of rules from the set of rules. 

7.3.4 Management of FAU_SAA.2 

The following actions could be considered for the management functions in FMT: 

a) maintenance (deletion, modification, addition) of the group of users in the profile target group. 

7.3.5 Management of FAU_SAA.3 

The following actions could be considered for the management functions in FMT: 
a) maintenance (deletion, modification, addition) of the subset of system events. 

7.3.6 Management of FAU_SAA.4 

The following actions could be considered for the management functions in FMT: 

a) maintenance (deletion, modification, addition) of the subset of system events; 

b) maintenance (deletion, modification, addition) of the set of sequence of system events. 

7.3.7 Audit of FAU_SAA.1 , FAU_SAA.2. FA0_SAA.3, FAU_SAA.4 

The following actions should be auditable if FAU_GEN Security audit data generation is Included in the 
PP/ST: 

a) Minimal: Enabling and disabling of any of the analysis mechanisms; 

b) Minimal: Automated responses performed by the tool. 

7.3.8 FAU_SAA.1 Potential violation analysis 
Hierarchical to: No other components. 
Dependencies: FAU_GEN. 1 Audit data generation 

7.3.8.1 FAU_SAA.1.1 

The TSF shall be able to apply a set of rules in monitoring the audited events and based upon these 
rules indicate a potential violation of the TSP. 

7.3.8.2 FAU_SAA.1.2 

The TSF shall enforce the following rutes for monitoring audited events: 

a) Accumulation or combination of [assignment: subset of defined auditable events] known to 
indicate a potential security violation; 

b) [assignment: any ot/ierw/es]. 
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7.3.9 FAU_SAA.2 Profile based anomaly detection 

Hierarchical to: FAU_SAA.1 Potential violation analysis 
Dependencies: FIA_UID.1 Timing of identification 

7.3.9.1 FAU_SAA.2.1 

The TSF shall be able to maintain profiles of system usage, where an individual profile represents the 
historical patterns of usage performed by the member(s) of [assignment: the profile target group], 

7.3.9.2 FAU_SAA.2.2 

The TSF shall be able to maintain a suspicion rating associated with each user whose activity is 
recorded in a profile, where the suspicion rating represents the degree to which the user's current 
activity is found inconsistent with the established patterns of usage represented in the profile. 

7.3.9.3 FAU_SAA.2.3 

The TSF shall be able to indicate an imminent violation of the TSP when a user's suspicion rating 
exceeds the following threshold conditions [assignment: conditions under which anomalous activity 
is reported by the TSF\. 

7.3.10 FAU_SAA.3 Simple attack heuristics 

Hierarchical to: FAU_SAA.1 Potential violation analysis 
Dependencies: No dependencies. 

7.3.10.1 FAU_SAA.3.1 

The TSF shall be able to maintain an internal representation of the following signature events 
[assignment: a subset of system events] that may Indicate a violation of the TSP. 

7.3.10.2 FAU_SAA.3.2 

The TSF shall be able to compare the signature events against the record of system activity discernible 
from an examination of [assignment: the information to be used to determine system activity. 

7.3.10.3 FAU_SAA.3,3 

The TSF shall be able to indicate an imminent violation of the TSP when a system event is found to 
match a signature event that indicates a potential violation of the TSP. 

7.3.11 FAU_SAA.4 Complex attack heuristics 

Hierarchical to: FAU_SAA.3 Simple attack heuristics 

Dependencies: No dependencies. 

7.3.11.1 FAU_SAA.4.1 

The TSF. shall be able to maintain an internal representation of the following event sequences of known 
intrusion scenarios [assignment: list of sequences of system events whose occurrence are 
representative of known penetration scenarios] and the following signature events [assignment: a subset 
of system events] that may indicate a potential violation of the TSP. 
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7.3.11.2 FAU_SAA.4.2 

The TSF shall be able to compare the signature events and event sequences against the record of system 
activity discernible from an examination of [assignment: the information to be used to determine system 
activity]. 

7.3.11.3 FAU_SAA.4.3 

The TSF shall be able to indicate an imminent violation of the TSP when system activity is found to match a 
signature event or event sequence that indicates a potential violation of the TSP. 

7.4 Security audit review (FAU_SAR) 

7.4.1 Family Behaviour 

This family defines the requirements for audit tools that should be available to authorised users to assist in the 
review of audit data. 



7.4.2 Component levelling 



FAU_SAR: Security audit review 




Figure 13 - FAU_SAR component levelling 

FAU_SAR.1 Audit review, provides the capability to read information from the audit records. 

FAU_SAR.2 Restricted audit review, requires that there are no other users except those that have been 
identified in FAU_SAR. 1 Audit review that can read the information. 

FAU_SAR.3 Selectable audit review, requires audit review tools to select the audit data to be reviewed based 
on criteria. 

7.4.3 Management of FAU.SAR.I 

The following actions could be considered for the management functions in FMT: 

a) maintenance (deletion, modification, addition) of the group of users with read access right to the audit 
records. 

7.4.4 Management of FAU_SAR.2, FAU_SAR.3 

There are no management activities foreseen. 

7.4.5 Audit Of FAU_SAR.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Basic: Reading of infonnation from the audit records. 
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7.4.6 Audit of FAU_SAR.2 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Basic: Unsuccessful attempts to read information from the audit records. 

7.4.7 Audit of FAU_SAR.3 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Detailed: the parameters used for the viewing. 

7.4.8 FAU_SAR.1 Audit review 

Hierarchical to: No other components. 
Dependencies: FAU_GEN.1 Audit data generation 

This component will provide authorised users the capability to obtain and interpret the information. In case of 
human users this information needs to be in a human understandable presentation. In case of external IT 
entities the information needs to be unambiguously represented in an electronic fashion. 

7.4.8.1 FAU_SAR.1.1 

The TSF shall provide [assignment: authorised users] with the capability to read [assignment: list of 
audit information] from the audit records. 

7.4.8.2 FAU_SAR.1.2 

The TSF shall provide the audit records in a manner suitable for the user to interpret the information. 

7.4.9 FAU_SAR.2 Restricted audit review 

Hierarchical to: No other components. 

Dependencies: FAU_SAR.1 Audit review 

7.4.9.1 FAU_SAR.2.1 

The TSF shall prohibit all users read access to the audit records, except those users that have been 
granted explicit read-access. 

7.4.10 FAU_SAR.3 Selectable audit review 

Hierarchical to: No other components. 

Dependencies: FAU_SAR.1 Audit review 

7.4.10.1 FAU_SAR.3.1 

The TSF shall provide the ability to perform [selection: searches,sorting,ordering] of audit data based 
on [assignment: criteria with logical relations]. 
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7.5 Security audit event selection (FAU_SEL) 

7.5.1 Family Behaviour 

This family defines requirements to select the events to be audited during TOE operation. It defines 
requirements to include or exclude events from the set of auditable events. 

7.5.2 Component levelling 



FAU_SEL: Security audit event selection 



Figure 14 - FAU_SEL component levelling 

FAU_SEL.1 Selective audit, requires the ability to include or exclude events from the set of audited events 
based upon attributes to be specified by the PP/ST author, 

7.5.3 Management of FAU_SEL.1 

The following actions could be considered for the management functions in FMT: 
a) maintenance of the rights to view/modify the audit events. 

7.5.4 Audit of FAU_SEL.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: All modifications to the audit configuration that occur while the audit collection functions are 
operating. 

7.5.5 FAU_SEL.1 Selective audit 

Hierarchical to: No other components. 

Dependencies: FAU_GEN. 1 Audit data generation 

FMT_MTD.1 Management of TSF data 

7.5.5.1 FAU_SEL.1.1 

The TSF shall be able to include or exclude auditable events from the set of audited events based on 
the following attributes: 

a) [selection: object idenVly.user identity,subject identity,host identity, event type] 

b) [assignment: iist of additional attributes that audit selectivity is based upon] 
7.6 Security audit event storage (FAU_STG) 

7.6.1 Family Behaviour 

This family defines the requirements for the TSF to be able to create and maintain a secure audit trail. 
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7.6.2 Component levelling 



FAUSTG: Security audit event storage 



I 2 

3 4 



Figure 15 - FAU_STG component levelling 

At FAU_STG.1 Protected audit trail storage, requirements are placed on the audit trail. It will be protected 
from unauthorised deletion and/or modification. 

FAU_STG.2 Guarantees of audit data availability, specifies the guarantees that the TSF maintains over the 
audit data given the occurrence of an undesired condition. 

FAU_STG.3 Action in case of possible audit data loss, specifies actions to be taken if a threshold on the audit 
trail is exceeded. 

FAU_STG.4 Prevention of audit data loss, specifies actions in case the audit trail Is full. 

7.6.3 Management of FAU_STG.1 

There are no management activities foreseen. 

7.6.4 Management of FAU_STG.2 

The following actions could be considered for the management functions tn FMT: 
a) maintenance of the parameters that control the audit storage capability. 

7.6.5 Management of FAU_STG.3 

The following actions could be considered for the management functions in FMT: 

a) maintenance of the threshold; 

b) maintenance (deletion, modification, addition) of actions to be taken in case of imminent audit storage 
failure. 

7.6.6 Management of FAU_STG.4 

The following actions could be considered for the management functions in FMT: 

a) maintenance (deletion, modification, addition) of actions to be taken in case of audit storage failure. 

7.6.7 Audit of FAU_STG.1 , FAU_STG.2 
There are no auditabte events foreseen. 

7.6.8 Audit of FAU_STG.3 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Basic: Actions taken due to exceeding of a threshold. 
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7.6.9 Audit of FAU STG.4 



The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Basic: Actions taken due to the audit storage failure. 

7.6.10 FAU_STG.1 Protected audit trail storage 
Hierarchical to: No other components. 
Dependencies: FAU_GEN.1 Audit data generation 

7.6.10.1 FAU_STG.1.1 

The TSF shall protect the stored audit records from unauthorised deletion. 

7.6.10.2 FAU_STG.1.2 

The TSF shall be able to [selection, choose one of: prevent,detecf\ unauthorised modifications to the 
stored audit records In the audit trail. 

7.6.11 FAU_STG.2 Guarantees of audit data availability 

Hierarchical to: FAU_STG.1 Protected audit trail storage 
Dependencies: FAU_GEN.1 Audit data generation 

7.6.11.1 FAU_STG.2.1 

The TSF shall protect the stored audit records from unauthorised deletion. 

7.6.11.2 FAU_STG.2.2 

The TSF shall be able to tselection, choose one of: prevent,detecf\ unauthorised modifications to the stored 
audit records in the audit trail. 

7.611.3 FAU_5TG.:^.3 

The TSF shall ensure that [assignment: metric for saving audit records] audit records will be 
maintained when the following conditions occur: [selection: audit storage exhaustioii,failure,attack\ 

7.6.12 FAU_STG.3 Action in case of possible audit data loss 

Hierarchical to: No other components. 

Dependencies: FAU_STG.1 Protected audit trail storage 

7.6.12.1 FAU_STG.3.1 

The TSF shall [assignment: acVons to be tal(en in case of possible audit storage failure] if the audit 
trail exceeds [assignment: pre-deff/ied ///nil]. 

7.6.13 FAU_STG.4 Prevention of audit data loss 

Hierarchical to: FAU_STG.3 Action in case of possible audit data loss 
Dependencies: FAU_STG.1 Protected audit trail storage 
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7.6.13.1 FAU_STG.4.1 

The TSF shall [selection, choose one of: "ignore auditable evente", "prevent auditable events, except 
those taken by the authorised user with special rights", "overwrite the oldest stored audit records'^ 

and [assignment: other actions to be taken in case of audit storage failure] if the audit trail is full. 

8 Class FCO: Communication 

This class provides two families specifically concerned with assuring the identity of a party participating in a 
data exchange. These families are related to assuring the identity of the originator of transmitted information 
(proof of origin) and assuring the identity of the recipient of transmitted information (proof of receipt). These 
families ensure that an originator cannot deny having sent the message, nor can the recipient deny having 
received it. 



FCONRO: Non-repxidiation of origui 



FCO_NRR: Non-repudiation of receipt 



Figure 16- FCO: Communication class decomposition 
8.1 Non-repudiation of origin (FCO_NRO) 

8.1.1 Family Behaviour 

Non-repudiation of origin ensures that the originator of information cannot successfully deny having sent the 
information. This family requires that the TSF provide a method to ensure that a subject that receives 
information during a data exchange is provided with evidence of the origin of the information. This evidence 
can then be verified by either this subject or other subjects. 

8.1.2 Component levelling 



FCO NRC): Non-repudiation of origin 



Figure 17 - FCO_NRO component levelling 

FC0_NR0.1 Selective proof of origin, requires the TSF to provide subjects with the capability to request 
evidence of the origin of information. 

FC0_NR0.2 Enforced proof of origin, requires that the TSF always generate evidence of origin for transmitted 
information. 

8.1 .3 Management of FC0_NR0.1, FC0_NR0.2 

The following actions could be considered for the management functions in FMT: 

a) The management of changes to information types, fields, originator attributes and recipients of evidence. 

8.1.4 Audit of FC0_NR0.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: The identity of the user who requested that evidence of origin would be generated. 

b) Minimal: The invocation of the non-repudiation service. 
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c) Basic; Identification of the information, the destination, and a copy of the evidence provided. 

d) Detailed: The identity of the user who requested a verification of the evidence. 

8.1.5 Audit of FC0_NR0.2 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: The invocation of the non-repudiation service. 

b) Basic: Identification of the information, the destination, and a copy of the evidence provided. 

c) Detailed: The identity of the user who requested a verification of the evidence. 

8.1.6 FC0_NR0.1 Selective proof of origin 
Hierarchical to: No other components. 
Dependencies: FIA_UID.1 Timing of identification 

8.1.6.1 FC0_NR0.1.1 

The TSF shall be able to generate evidence of origin for transmitted [assignment: list of information 
types] at the request of the [selection: originator, recJpientJassignment: iist of third parties]]. 

8.1.6.2 FC0_NR0.1.2 

The TSF shall be able to relate the [assignment: list of attributes] of the originator of the information, 
and the [assignment: list of information fields] of the information to which the evidence applies. 

8.1.6.3 FC0_NR0.1.3 

The TSF shall provide a capability to verify the evidence of origin of information to [selection: 
originator, recipient,[assignment list of third parties]] given [assignment: limitations on the evidence 
of origin]. 

8.1 .7 FCO_NR0.2 Enforced proof of origin 

Hierarchical to: FC0_NR0.1 Selective proof of origin 
Dependencies: FIA_UID.1 Timing of identification 

8.1.7.1 FC0_NR0.2.1 

The TSF shall enforce the generation of evidence of origin for transmitted [assignment: list of information 
types] at all times. 

8.1.7.2 FCO_NR0.2.2 

The TSF shall be able to relate the [assignment: list of attributes] of the originator of the information, and the 
[assignment: list of information fields] of the information to which the evidence applies. 

8.1.7.3 FCO_NR0.2.3 

The TSF shall provide a capability to verify the evidence of origin of information to [selection: originator, 
recipient,[assignment: list of third parties]] given [assignment: limitations on the evidence of origin]. 
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8.2 Non-repudiation of receipt (FCO_NRR) 
8.2.1 Family Behaviour 



Non-repudiation of receipt ensures ttiat the recipient of information cannot successfully deny receiving the 
information. This family requires that the TSF provide a method to ensure that a subject that transmits 
information during a data exchange is provided with evidence of receipt of the information. This evidence can 
then be verified by either this subject or other subjects. 



8.2.2 Component levelling 



FCO NRR: Non-repudiation of receipt 



Figure 18 - FCO_NRR component levelling 

FC0_NRR.1 Selective proof of recfeipt, requires the TSF to provide subjects with a capability to request 
evidence of the receipt of information. 

FC0_NRR.2 Enforced proof of receipt, requires that the TSF always generate evidence of receipt for received 

information. 

8.2.3 Management of FCO_NRR.1,FCO_NRR.2 

The following actions could be considered for the management functions In FMT: 

a) The management of changes to information types, fields, originator attributes and third parties recipients 
of evidence. 

8.2.4 Audit Of FCO^NRR.I 

The following actions should be auditable if FAU_GEN SBCurity audit data generation is included in the 
PP/ST: 

a) Minimal: The identity of the user who requested that evidence of receipt would be generated. 

b) Minimal: The invocation of the non-repudiation service. 

c) Basic: Identification of the information, the destination, and a copy of the evidence provided. 

d) Detailed: The identity of the user who requested a verification of the evidence. 

8.2.5 Audit of FC0_NRR.2 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 

PP/ST: 

a) Minimal: The invocation of the non-repudiation service. 

b) Basic: Identification of the infomnation, the destination, and a copy of the evidence provided. 

c) Detailed: The identity of the user who requested a verification of the evidence. 

8.2.6 FC0_NRR.1 Selective proof of receipt 

Hierarchical to: No other components. 
Dependencies: FIA_UID.1 Timing of identification 
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8.2.6.1 FCO NRR.1.1 



The TSF shall be able to generate evidence of receipt for received [assignment: list of information 
types] at the request of the [selection: originator, recipientjassignment: list of ttiird parties}]. 

8.2.6.2 FC0_NRR.1.2 

The TSF shall be able to relate the [assignment: list of attributes] of the recipient of the information, 
and the [assignment: list of Information fields] of the information to which the evidence applies. 

8.2.6.3 FC0_NRR.1.3 

The TSF shall provide a capability to verify the evidence of receipt of information to [selection: 
originator, recipient,[assignment: list of third parties^ given [assignment: limitations on the evidence 
of receipt]. 

8.2.7 FC0_NRR.2 Enforced proof of receipt 

Hierarchicalto: FC0_NRR.1 Selective proof of receipt 
Dependencies: FIA_UID.1 Timing of identification 

8.2.7.1 FC0_NRR.2.1 

The TSF shall enforce the generation of evidence of receipt for received [assignment: list of information 
types]. 

8.2.7.2 FCO_NRR.2.2 

The TSF shall be able to relate the [assignment: list of attributes] of the recipient of the information, and the 
[assignment: list JDf information fields] of the information to which the evidence applies. 

8.2.7.3 FCO_NRR.2.3 

The TSF shall provide a capability to verify the evidence of receipt of information to [selection: originator, 
recipient,[8rssignment: list of third partiesj] given [assignment: limitations on the evidence of receipt]. 

9 Class PCS: Cryptographic support 

The TSF may employ cryptographic functionality to help satisfy several high-level security objectives. These 
include (but are not limited to): identification and authentication, non-repudiation, trusted path, trusted channel 
and data separation. This class is used when the TOE implements cryptographic functions, the 
implementation of which could be in hardware, firmware and/or software. 

The FCS: Cryptographic support class is composed of two families: Cryptographic key management 
{FCS_CKM) and Cryptographic operation (FCS_COP). The Cryptographic key management (FCS_CKM) 
family addresses the management aspects of cryptographic keys, while the Cryptographic operation 
(FCS_COP) family is concerned with the operational use of those cryptographic keys. 
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FCSCKM: Cryptographic key management 




FCSCOP: Cryptographic operation 



Figure 19 - FCS: Cryptographic support class decomposition 

9.1 Cryptographic key management (FCS_CKIVI) 

9.1 .1 Family Behaviour 

Cryptographic keys must be managed throughout their life cycle. This family is intended to support that 
lifecycle and consequently defines requirements for the following activities: cryptographic key generation, 
cryptographic key distribution, cryptographic key access and cryptographic key destruction. This family should 
be included whenever there are functional requirements for the management of cryptographic keys. 

9.1 .2 Component levelling 



FCS CKM: Clryptographic key management 




Figure 20 - FCS_CKIVI component levelling 

FCS_CKM.1 Cryptographic key generation, requires cryptographic keys to be generated in accordance with a 
specified algorithm and key sizes which can be based on an assigned standard. 

FCS_CKM.2 Cryptographic key distribution, requires cryptographic keys to be distributed in accordance with a 
specified distribution method which can be based on an assigned standard. 

FCS_CKM.3 Cryptographic key access, requires access to cryptographic keys to be performed in accordance 
with a specified access method which can be based on an assigned standard. 

FCS_CKM.4 Cryptographic key destruction, requires cryptographic keys to be destroyed in accordance with a 
specified destruction method which can be based on an assigned standard. 

9.1 .3 IWanagement of FCS_CKM.1 , FCS_CKM.2, FCS_CKI\/i.3, FCS_CKM.4 

The following actions could be considered for the management functions in FMT: 

a) the management of changes to cryptographic key attributes. Examples of key attributes include user, key 
type (e.g. public, private, secret), validity period, and use (e.g. digital signature, key encryption,' key 
agreement, data encryption). 
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9.1 .4 Audit of FCS_CKM.1 , FCS_CKM.2, FCS_CKM.3, FCS_CKM.4 



The following actions should be auditable if FAU GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: Success and failure of the activity. 

b) Basic: The object attribute(s), and object value(s) excluding any sensitive information (e.g. secret or 
private keys). 

9.1 .5 FCS_CKM.1 Cryptographic icey generation 

Hierarchical to; No other components. 

Dependencies: IFCS_CKM.2 Cryptographic key distribution, or 

FCS_COP. 1 Cryptographic operation] 

FCS_CKM.4 Cryptographic key destruction 

FMT_MSA.2 Secure security attributes 

9.1.5.1 FCS_CKM.1.1 

The TSF shall generate cryptographic keys in accordance with a specified cryptographic key 
generation algorithm [assignment: cryptographic key generation algorithm] and specified 
cryptographic key sizes [assignment: cryptographic liey sizes\ that meet the foi lowing: Assignment: 
iist of standard^. 

9.1.6 FCS_CKM.2 Cryptographic key distribution 

Hierarchical to: No other components. 

Dependencies: [FDPJTC.1 Import of user data without security attributes, or 

FDP_ITC.2 Import of user data with security attributes, or 

FCS_CKM.1 Cryptographic key generation] 

FCS_CKM.4 Cryptographic key destruction 

FMT_MSA.2 Secure security attributes 

9.1.6.1 FCS_CKM,2.1 

The TSF shall distribute cryptographic keys in accordance with a specified cryptographic key 
distribution method [assignment: cryptographic key distribution method\ that meets the following: 
[assignment: list of standards]. 

9.1 .7 FCS_CKM.3 Cryptographic key access 

Hierarchical to: No other components. 

Dependencies: IFDPJTC.1 Import of user data without security attributes, or 
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FDP_ITC.2 Import of user data with security attributes, or 

FCS_CKM.1 Cryptographic key generation] 

FCS_CKM.4 Cryptographic key destruction 

FMT_MSA.2 Secure security attributes 

9.1.7.1 FCS_CKM.3.1 

The TSF shall perform [assignment: type of cryptographic key access] in accordance with a specified 
cryptographic key access method [assignment: cryptographic Itey access methodi that meets the 
following: [assignnjent: list of standards], 

9.1.8 FCS_CKM.4 Cryptographic key destruction 

Hierarchical to: No other compone^nts. 

Dependencies. [FDPJTG.1 Import of user data without security attributes, or 

FDP_tTC.2 Import of user data with security attributes, or 

FCS_CKM.1 Cryptographic key generation] 

FMT_MSA.2 Secure security attributes 

9.1.8.1 FCS_CKM.4.1 

The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key 
destruction method [assignment: cryptographic Icey destruction method] that meets the following: 
[assignment: list of standards]. 

9.2 Cryptographic operation (FCS_COP) 

9.2.1 Family Behaviour 

In order for a cryptographic operation to function correctly, the operation must be performed in accordance 
with a specified algorithm and with a cryptographic key of a specified size. This family should be included 
whenever there are requirements for cryptographic operations to be performed. 

Typical'cryptographic operations include data encryption and/or decryption, digital signature generation and/or 
verification, cryptographic checksum generation for integrity and/or verification of checksum, secure hash 
(message digest), cryptographic key encryption and/or decryption, and cryptographic key agreement. 

9.2.2 Component levelling 



FCSCOP: Cryptographic operation 



Figure 21 - FCS_COP component levelling 

FCS_C0P.1 Cryptographic operation, requires a cryptographic operation to be performed in accordance with 
a specified algorithm and with a cryptographic key of specified sizes. The specified algorithm and 
cryptographic key sizes can be based on an assigned standard. 

9.2.3 Management of FCS_C0P.1 

There are no management activities foreseen. 
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9.2.4 Audit of FCS C0P.1 



The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: Success and failure, and the type of cryptographic operation. 

b) Basic: Any applicable cryptographic mode(s) of operation, subject attributes and object attributes. 
9.2.5 FCS_C0P.1 Cryptographic operation 

Hierarchical to: No other components. 

Dependencies: [FDPJTC.I Import of user data without security attributes, or 

FDP_ITC.2 Import of user data with security attributes, or 

FCS_CKM.1 Cryptographic key generation] 

FCS_CKM.4 Cryptographic key destruction 

FMT_MSA.2 Secure security attributes 

9.2.5.1 FCS_COP.1.1 

The TSF shall perform [assignment: list of cryptographic operations] in accordance with a specified 
cryptographic algorithm [assignment: cryptographic algorithm] and cryptographic key sizes 
[assignment: cryptographic key sizes] that meet the following: [assignment: list of standards]. 

10 Class FDP: User data protection 

This class contains families specifying requirements for TOE security functions and TOE security function 
policies related to protecting user data. FDP: User data protection is split into four groups of families (listed 
below) that address user data within a TOE, during import, export, and storage as well as security attributes 
directly related to user data. 

The families in this class are organised into four groups: 

a) User data protection security function policies: 

• Access control policy (FDP_ACC); and 

• Information flow control policy (FDP_IFC). 

Components in these families permit the PP/ST author to name the user data protection security function 
policies and define the scope of control of the policy, necessary to address the security objectives. The 
names of these policies are meant to be used throughout the remainder of the functional components that 
have an operation that calls for an assignment or selection of an "access control SFP" or an "information 
flow control SFP". The rules that define the functionality of the named access control and information flow 
control SFPs will be defined in the Access control functions (FDP_ACF) and Information flow control 
functions (FDP_IFF) families (respectively). 

b) Forms of user data protection: 

• Access control functions (FDP_ACF); 

• Information flow control functions (FDP_IFF); 



29 



IS 14990 (Part 2): 2006 
ISO/IEC 15408-2: 2005 

• Internal TOE transfer (FDPJTT) ; 

• Residual information protection (FDP_RIP); 

• Rollback (FDP_ROL); and 

• Stored data integrity (FDP_SDI). 

c) Off-line storage, import and export: 

• Data authentication (FDP_DAU); 

• Export to outside TSF control (FDP_ETC); 

• Import from outside TSF control (FDPJTC). 

Components in these families address the trustworthy transfer into or out of the TSC. 

d) Inter-TSF communication: 

• Inter-TSF user.data confidentiality transfer protection (FDP_UCT); and 

• Inter-TSF user data integrity transfer protection (FDP_UIT). 

Components in these families address communication between the TSF of the TOE and another trusted 
IT product. 
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FDP_ACC: Access control policy 



FDP_ACF: Access Control fiincfions 



FDP DAU: Data authentication 



FDP_ETC: Export to outside TSF control 



FDPEFC; Infonnation flow control policy 



FDPJFF: Lifonnation flow control fimctions 



FDP_rrC: Import from outside TSF control 



FDPITT: lilemal TOE transfer 



FDPRIP: Residual information protection 



FDP ROL: Rollback 



FDP_SDI: Stored data integrity 



FDP_UCT: Inter-TSF user data confidentiality transfer protection 



FDP_UIT: Intcr-TSF user data integrity trajisfer protection 
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Figure 22 - FDP: User data protection class decomposition 
10.1 Access control policy (FDP_ACC) 

10.1.1 Family Behaviour 

This family identifies the access control SFPs (by name) and defines the scope of control of the policies that 
form the identified access control portion of the TSP. This scope of control is characterised by three sets: the 
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subjects under control of the policy, the objects under control of the policy, and the operations among 
controlled subjects and controlled objects that are covered by the policy. The criteria allows multiple policies to 
exist, each having a unique name. This is accomplished by iterating components from this family once for 
each named access control policy. The rules that define the functionality of an access control SFP will be 
defined by other families such as Access control functions (FDP_ACF) and Stored data integrity (FDP_SDI). 
The names of the access control SFPs identified here in Access control policy (FDP_ACC) are meant to be 
used throughout the remainder of the functional components that have an operation that calls for an 
assignment or selection of an "access control SFP." 

'10.1.2 Connponent levelling 



FDP ACC: Access control policy 



Figure 23 - FDP_ACC component levelling 

FDP_ACC.1 Subset access control, requires that each identified access control SFP be in place for a subset 
of the possible operations on a subset of the objects in the TOE. 

FDP_ACC.2 Complete access control, requires that each identified access control SFP cover all operations 
on subjects and objects covered by that SFP. It further requires that all objects and operations with the TSC 
are covered by at least one identified access control SFP. 

10.1.3 Management of FDP_ACC.1, FDP_ACC.2 

There are no management activities foreseen. 

10.1.4 Audit of FDP_ACC.1, FDP_ACC.2 
There are no auditable events foreseen. 

10.1.5 FDP_ACC.1 Subset access control 
Hierarchical to: No other components. 

Dependencies: FDP_ACF.1 Security attribute based access control 
10.1.5.1 FDP_ACC.1.1 

The TSF shall enforce the [assignment: access control SFP\ on [assignment: list of subjects, objects, 
and operations among subjects and objects covered by the SFP\. 

10.1.6 FDP_ACC.2 Complete access control 

Hierarchical to: FDP_ACC.1 Subset access control 

Dependencies: FDP_ACF.1 Security attribute based access control 

10.1.6.1 FDP_ACC.2.1 

The TSF shall enforce the [assignment: access control SFP\ on [assignment: list of subjects and objects] and 
all operations among subjects and objects covered by the SFP. 

tO.1.6.2 FDP_ACC.2.2 

The TSF shall ensure that all operations between any subject in the TSC and any object within the TSC 
are covered by an access control SFP. 
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10.2 Access control functions (FDP_ACF) 

10.2.1 Family Behaviour 

This family describes the rules for the specific functions that can Implement an access control policy named in 
Access control policy (FDP_ACC). Access control policy (FDP_ACC) specifies the scope of control of the 
policy. 

10.2.2 Component levelling 



FDP ACF: Access control functions 



Figure 24 - FDP_ACF component levelling 

This family addresses security attribute usage and characteristics of policies. The component within this family 
is meant to be used to describe the rules for the function that implements the SFP as identified in Access 
control policy (FDP_ACC). The PP/ST author may also iterate this component to address multiple policies in 
the TOE. 

FDP_ACF.1 Security attribute based access control Security attribute based access control allows the TSF to 
enforce access based upon security attributes and named groups of attributes. Furthermore, the TSF may 
have the ability to explicitly authorise or deny access to an object based upon security attributes. 

10.2.3 Management of FDP_ACF.1 

The following actions could be considered for the management functions in FMT: 
a) Managing the attributes used to make explicit access or denial based decisions. 

10.2.4 Audit of FDP_ACF.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: Successful requests to perform an operation on an object covered by the SFP. 

b) Basic: All requests to perform an operation on an object covered by the SFP. 

c) Detailed: The specific security attributes used in making an access check. 

10.2.5 FDP_ACF.1 Security attribute based access control 
+iierarchical to: No other components. 

Dependencies: FDP_ACC.1 Subset access control 

FMT_MSA.3 Static attribute initialisation 
10.2.5.1 FDP_ACF.1.1 

The TSF shall enforce the [assignment: access control SFP\ to objects based on the following: 
[assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP- 
relevant security attributes, or named groups of SFP-relevant security attributes]. 
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10.2.5.2 FDP_ACF.1.2 

The TSF shall enforce the following rules to determrne if an operation among controlled subjects and 
controlled objects is allowed: [assignment: rules governing access among controlled subjects and 
controlled objects using controlled operations on controlled objects]. 

10.2.5.3 FDP_ACF.1.3 

The TSF shall explicitly authorise access of subjects to objects based on the following additional 
rules: [assignment: rules, based on security attributes, that explicitly authorise access of subjects to 
objects]. 

10.2.5.4 FDP_ACF.1.4 

The TSF shall explicitly deny access of subjects to objects based on the [assignment: rules, based on 
security attributes, that explicitly deny access of subjects to objects]. 

10.3 Data authentication (FDP_DAU) 

10.3.1 Family Behaviour 

Data authentication permits an entity to accept responsibility for the authenticity of information (e.g.. by 
digitally signing it). This family provides a method of providing a guarantee of the validity of a specific unit of 
data that can be subsequently used to verify that the information content has not been forged or fraudulently 
modified. In contrast to FAU: Security audit, this family is intended to be applied to "static" data rather than 
data that is being transferred. 

10.3.2 Component levelling 



FDP DAU; Data authentication 



Figure 25 - FDP_DAU component levelling 

FDP_DAU.1 Basic Data Authentication, requires that the TSF is capable of generating a guarantee of 
authenticity of the information content of objects (e.g. documents). 

FDP_DAU.2 Data Authentication with Identity of Guarantor additionally requires that the TSF is capable of 
establishing the identity of the subject who provided the guarantee of authenticity. 

10.3.3 Management of FDP_DAU.1, FDP_DAU.2 

The following actions could be considered for the management functions in FMT: 

a) The assignment or modification of the objects for which data authentication may apply could be 
configurable in the system. 

10.3.4 Audit of FDP_DAU.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: Successful generation of validity evidence. 

b) Basic: Unsuccessful generation of validity evidence. 

c) Detailed: The identity of the subject that requested the evidence. 
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10.3.5 Audit of FDP 0AU.2 



The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: Successful generation of validity evidence. 

b) Basic: Unsuccessful generation of validity evidence. 

c) Detailed: The identity of the subject that requested the evidence. 

d) Detailed: The identity of the subject that generated the evidence. 

10.3.6 FDP_DAU.1 Basic Data Authentication 
Hierarchical to: No other components. 
Dependencies: No dependencies. 

10.3.6.1 FDP_DAU.1.1 

The TSF shall provide a capability to generate evidence that can be used as a guarantee of the validity 
of [assignment: list of objects or information types]. 

10.3.6.2 FDP_DAU.1.2 

The TSF shall provide [assignment: list of subjects] with the ability to verify evidence of the validity of 
the indicated information. 

10.3.7 FDP_DAU.2 Data Authentication with identity ot Guarantor 

Hierarchical to: FDP_DAU.1 Basic Data Authentication 
Dependencies: FIA_UID.1 Timing of identification 

10.3.7.1 FDP_DAU.2.1 

The TSF shall provide a capability to generate evidence that can be used as a guarantee of the validity of 
[assignment: list of objects or information types]. 

10.3.7.2 FDP_DAU.2.2 

The TSF shall provide [assignment: list of subjects] with the ability to verify evidence of the validity of the 
indicated information and the identity of the user that generated the evidence. 

10.4 Export to outside TSF control (FDP_ETC) 

10.4.1 Family Behaviour 

This family defines functions for exporting user data from the TOE such that its security attributes and 
protection either can be explicitly preserved or can be ignored once it has been exported. It is concemed with 
limitations on export and with the association of security attributes with the exported user data. 
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10.4.2 Component levelling 



FDPETC: Export to outside TSF control 




Figure 26 - FDP_ETC component levelling 

FDP_ETC.1 Export of user data without security attributes, requires that the TSF enforce the appropriate 
SFPs when exporting user data outside the TSF. User data that is exported by this function is exported 
without its associated security attributes. 

FDP_ETC.2 Export of user data with security attributes, requires that the TSF enforce the appropriate SFPs 
using a function that accurately and unambiguously associates security attributes with the user data that Is 
exported. 

1 0.4.3 Management of FDP_ETC.1 

There are no management activities foreseen. 

10.4.4 Management of FDP_ETC.2 

The following actions could be considered for the management functions in FMT: 

a) The additional exportation control rules could be configurable by a user in a defined role. 

10.4.5 Audit of FDP_ETC.1,FDP_ETC.2 

The following actions should be auditabte if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: Successful export of information. 

b) Basic: All attempts to export information. 

10.4.6 FDP_ETC.1 Export of user data witliout security attributes 
Hierarchical to: No other components. 

Dependencies: [FDP_ACC.1 Subset access control, or 

FDPJFC.I Subset information flow control] 

10.4.6.1 FDP_ETC.1.1 

The TSF shall enforce the [assignment: access control $FP(s) and/or intormation flow control BFP(sJi 
when exporting user data, controlled under the SFP(s), outside of the TSC. 

10.4.6.2 FDP_ETC.1.2 

The TSF shall export the user data without the user data's associated security attributes 

10.4.7 FDP_ETC.2 Export of user data with security attributes 

Hierarchical to: No other components. 
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Dependencies; [FDP_ACC.1 Subset access control, or 

FDP_IFC.1 Subset information flow control] 

10.4.7.1 FDP_ETC.2.1 

The TSF shall enforce the [assignment: access control SFP(s} and/or information flow control SFP(5j\ 
when exporting user data, controlled under the SFP{s), outside of the TSC. 

10.4.7.2 FDP_ETC.2.2 

The TSF shall export the user data with the user data's associated security attributes. 

10.4.7.3 FDP_ETC.2.3 

The TSF shall ensure that the security attributes, when exported outside the TSC, are unambiguously 
associated with the exported user data. 

10.4.7.4 FDP_ETC.2.4 

The TSF shall enforce the following rules when user data is exported from the TSC: [assignment: 
additional exportation control rules], 

10.5 Information flow control policy (FDPJFC) 

10.5.1 Family Behaviour 

This family identifies the Information flow control SFPs (by name) and defines the scope of control of the 
policies that form the identified information flow control portion of the TSF. This scope of control is 
characterised by three sets: the subjects under control of the policy, the information under control of the policy, 
and operations which cause controlled information to flow to and from controlled subjects covered by the 
policy. The criteria allows multiple policies to exist, each having a unique name. This is accomplished by 
iterating components from this family once for each named information flow control policy. The rules that 
define the functionality of an information flow control SFP will be defined by other families such as Information 
flow control functions (FDP_IFF) and Stored data integrity (FDP_SDI). The names of the information flow 
control SFPs identified here in Information flow control policy (FDP_fFC) are meant to be used throughout the 
remainder of the functional components that have an operation that calls for an assignment or selection of an 
"information flow control SFP." 

The TSF mechanism controls the flow of information in accordance with the information flow control SFP. 
Operations that would change the security attributes of information are not generally permitted as this would 
be in violation of an information flow control SFP. However, such operations may be permitted as exceptions 
to th^e information flow control SFP if explicitly specified. 

10.5.2 Component levelling 



FDPIFC: Infonnation flow control policy 



Figure 27 - FDPJFC component levelling 

FDP_IFC.1 Subset information flow control, requires that each identified information flow control SFPs be in 
place for a subset of the possible operations on a subset of information flows in the TOE. 

FDPJFC.2 Complete information flow control, requires that each identified information flow control SFP cover 
all operations on subjects and information covered by that SFP. It further requires that all information flows 
and operations with the TSC are covered by at least one identified information flow control SFP, In conjunction 
with the FPT_RVM.-1 component, this gives the "always invoked" aspect of a reference monitor. 
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10.5.3 Management of FDPJFC.1, FDPJFC.2 

There are no management activities foreseen. 

10.5.4 Audit of FDPJFd, FDPJFC.2 
There are no auditable events foreseen. 

10.5.5 FDPJFC.I Subset information flow control 

Hierarchical to: No other components. 

Dependencies: FDPJFF.1 Simple security attributes 

10.5.5.1 FDPJFC.1.1 

The TSF shall enforce the [assignment: information flow control SFP\ on [assignment: list of subjects, 
information, and operations that cause controlled information to flow to and from controlled subjects 
covered by the SFP^. 

10.5.6 FDP_IFC.2 Complete information flow control 

Hierarchical to: FDPJFd Subset information flow control 
Dependencies: FDPJFF.1 Simple security attributes 

10.5.6.1 FDPJFC.2.1 

The TSF shall enforce the [assignment: infonvation flow control SFP] on [assignment: list of subjects and 
information] and all operations that cause that information to flow to and from subjects covered by the SFP. 

10.5.6.2 FDPJFC.2.2 

The TSF shall ensure that all operations that cause any information in the ISC to flow to and from any 
subject in the TSC are covered by an information flow control SFP. 

10.6 Information flow control functions (FDPJFF) 

10.6.1 Family Behaviour 

This family describes the rules for the specific functions that can implement the information flow control SFPs 
named in Information flow control policy (FDPJFC), which also specifies the scope of control of the policy. It 
consists of two kinds of requirements: one addressing the common information flow function issues, and a 
second addressing illicit information flows (i.e. covert channels). This division arises because the issues 
concerning illicit information flows are, in some sense, orthogonal to the rest of an information flow control 
SFP. By their nature they circumvent the information flow control SFP resulting in a violation of the policy. As 
such, they require special functions to either limit or prevent their occurrence. 

10.6.2 Component levelling 



FDP IFF: Information flow control &inctions 




Figure 28 - FDPJFF component levelling 
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FDP_IFF.1 Simple security attributes, requires security attributes on information, and on subjects tliat cause 
that information to flow and on subjects that act as recipients of that information. It specifies the rules that 
must be enforced by the function, and describes how security attributes are derived by the function. 

FDP_IFF.2 Hierarchical security attributes expands on the requirements of FDP_iFF.1 Simple security 
attributes by requiring that all information flow control SFPs tn the TSP use hierarchical security attributes that 
form a lattice. 

FDPJFF.3 Limited illicit information flows, requires the SFP to cover illicit information flows, but not 
necessarily eliminate them. 

FDPJFF.4 Partial elimination of illicit information flows, requires the SFP to cover the elimination of some (but 
not necessarily all) illicit information flows. 

FDP_IFF.5 No illicit information flows, requires SFP to cover the elimination of all illicit information flows 

FDP_IFF.6 Illicit information flow monitoring, requires the SFP to monitor illicit information flows for specified 
and maximum capacities. 

10.6.3 Management of FDPJFF.1, FDPJFF.2 

The following actions could be considered for the management functions in FMT; 
a) Managing the attributes used to make explicit access based decisions. 

10.6.4 Management of FDPJFF.3, FDPJFF.4, FDPJFF.5 
There are no management activities foreseen. 

10.6.5 Management of FDPJFF.6 

The following actions could be considered for the management functions in FMT: 

a) The enabling or disabling of the monitoring function. 

b) Modification of the maximum capacity at which the monitonng occurs, 

10.6.6 Audit Of FDPJFF.1, FDPJFF.2, FDPJFF.5 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST. 

a) Minimal; Decisions to permit requested information flows. 

b) Basic: All decisions on requests for information flow. 

c) Detailed: The specific security attributes used in making an information flow enforcement decision. 

d) Detailed: Some specific subsets of the information that has flowed based upon policy goals (e.g. auditing 
of downgraded material). 

10.6.7 Audit of FDPJFF.3, FDPJFF.4, FDPJFF.S 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: Decisions to permit requested information flows. 

b) Basic: All decisions on requests for information flow. 
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c) Basic: The use of identified illicit information flow channels. 

d) Detailed: The specific security attributes used in making an information flow enforcement decision. 

e) Detailed: Some specific subsets of the information that has flowed based upon policy goals (e.g. auditing 
of downgraded material). 

f) Detailed: The use of identified illicit information flow channels with estimated maximum capacity 
exceeding a specified value. 

10.6.8 FDPJFF.I Simple security attributes 

Hierarchical to: No other components. 
Dependencies: FDPJFC.1 Subset information flow control 
FMT_MSA.3 Static attribute initialisation 

10.6.8.1 FDP_IFF.1.1 

The TSF shall enforce the [assignment: information flow control SFP\ based on the following types of 
subject and information security attributes: [assignment: list of subjects and information controlled 
under the indicated SFP, and for each, the security attributes]. 

10.6.8.2 FDPJFF.1.2 

The TSF shall permit an information flow between a controlled subject and controlled information via 
a controlled operation if the following rules hold: [assignment: for each operation, the security 
attribute-based relationship that must hold between subject and information security attributes]. 

tO.6.8.3 FDPJFF.1.3 

The TSF shall enforce the [assignment: additional information flow control SFP rules]. 

10.6.8.4 FDPJFF.1.4 

The TSF shall provide the following [assignment: list of additional SFP capabilities]. 

10.6.8.5 FDPJFF.I .5 

The TSF shall explicitly authrorise an information flow based on the following rules: [assignment: rules, 
based on security attributes, that explicitly authorise information flows]. 

tO.6.8.6 FDPJFF.I. 6 

The TSF shall explicitly deny an information flow based on the following rules: [assignment: rules, 
based on security attributes, that explicitly deny information flows], 

10.6.9 FDPJFF.2 Hierarchical security attributes 

Hierarchical to: FDPJFF.I Simple security attributes 
Dependencies: FDPJFC.1 Subset information flow control 
FMT MSA.3 Static attribute initialisation 
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10.6.9.1 FDP IFF.2.1 



The TSF shall enforce the [assignment; information flow control SFF] based on the following types of subject 
and information security attributes: [assignment: list of subjects and information controlled under the indicated 
SFP, and for each, the security attributes]. 

10.6.9.2 FDP_IFF.2.2 

The TSF shall permit an information flow between a controlled subject and controlled information via a 
controlled operation if the following rules, based on the ordering relationships between security attributes 
hold: [assignment: for each operation, the security attribute-based relationship that must hold between subject 
and information security attributes], 

10.6.9.3 FDPJFF.2.3 

The TSF shall enforce the [assignment: additional information flow control SFP rules]. 

10.6.9.4 FDPJFF.2.4 

The TSF shall provide the following [assignment: list of additional SFP capabilities]. 

10.6.9.5 FDP_IFF.2.5 

The TSF shall explicitly authorise an information flow based on the following rules: [assignment: rules, based 
on security attributes, that explicitly authorise infomnation flows]. 

1D.6.9.6 FDPJFF.2.6 

The TSF shall explicitly deny an information flow based on the following rules: [assignment: wles, based on 
security attributes, that explicitly deny information flows]. 

10.6.9.7 FDPJFF.2.7 

The TSF shall enforce the foilowing relationships for any two valid information flow control security 
attributes: 

a) There exists an ordering function that, given two valid security attributes, determines If the 
security attributes are equal, if one security attribute is greater than the other, or if the security 
attributes are incomparable; and 

b) There exists a "least upper bound" in the set of security attributes, such that, given any two valid 
security attributes, there is a valid security attribute that is greater than or equal to the two valid 
security attributes; and 

c) There exists a "greatest lower bound" in the set of security attributes, such that, given any two 
valid security attributes, there is a valid security attribute that is not greater than the two valid 
security attributes. 

10.6.10 FDPJFF.3 Limited illicit information flows 

Hierarchical to: No other components. 
Dependencies: AVA_CCA.1 Covert channel analysis 

FDPJFC.I Subset information flow control 
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10.6.10.1 FDPJFF.S.i 

The TSF shall enforce the [assignment: information flow control SFP\ to limit the capacity of 
[assignment: types of illicit information flows] to a [assignment: maximum capacity]. 

10.6.11 FDP_IFF.4 Partial elimination of illicit information flows 

Hierarchical to: FDPJFF.3 Limited illicit ir>formation flows 
Dependencies: AVA_CCA.1 Covert channel analysis 

FDP_IFC.1 Subset information flow control 

10.6.11.1 FDPJFF.4.1 

The TSF shall enforce the [assignment: information flow control SFP\ to limit the capacity of [assignment: 
types of illicit information flows] to a [assignment: maximum capacity]. 

10.6.11.2 FDPJFF.4.2 

The TSF shall prevent [assignment: types of illicit information flows]. 

10.6.12 FDPJFF.5 No illicit information flows 

Hierarchical to: FDP_IFF.4 Partial elimination of illicit information flows 

Dependencies: A\/A_CCA.3 Exhaustive covert channel analysis 

FDP_IFC.1 Subset information flow control 

10.6.12.1 FDPJFF.S.I 

The TSF shall ensure that no illicit information flows exist to circumvent [assignment: name of 
information flow control SFF^. 

1 0.6.1 3 FDP_IFF.6 Illicit information flow monitoring 

Hierarchical to: No other components. 

Dependencies: AVA_CCA.1 Covert channel analysis 

FDPJFC.1 Subset information flow control 

10.6.13.1 FDPJFF.6.1 

The TSF shall enforce the [assignment: information flow control SFF^ to monitor [assignment: fypes 
of illicit information flows] when it exceeds the [assignment: maximum capacity]. 

10.7 Import from outside TSF control (FDPJTC) 

10.7.1 Family Behaviour 

This farPiily defines the mechanisms for introduction of user data into the TOE such that it has appropriate 
security attributes and is appropriately protected. It is concerned with limitations on importation, determination 
of desired security attributes, and interpretation of security attributes associated with the user data. 
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10.7.2 Component levelling 



FDPITC: Import from outside TSF control 



Figure 29 - FDPJTC component levelling 

FDP_iTC.1 Import of user data without security attributes, requires that the security attributes correctly 
represent the user data and are supplied separately from the object. 

FDP_tTC.2 Import of user data with security attributes, requires that security attributes correctly represent the 
user data and are accurately and unambiguously associated with the user data imported from outside the TSC. 

10.7.3 Management of FDPJTC.I, FDPJTC.2 

The following actions could be considered for the management functions in FMT; 
a) The modification of the additional control rules used for import. 

10.7.4 Auditor FDPJTC.I, FDPJTC.2 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST; 

a) Minimal: Successful import of user data, including any security attributes. 

b) Basic: All attempts to import user data, including any security attributes. 

c) Detailed: The specification of security attributes for imported user data supplied by an authorised user. 

10.7.5 FDPJTC.I Import of user data without security attributes 
Hierarchical to: No other components. 

Dependencies: [FDP_ACC.1 Subset access control, or 

FDP_IFC.1 Subset information flow control] 
FMT_MSA.3 Static attribute initialisation 

10.7.5.1 FDPJTC.I. 1 

The TSF shall enforce the [assignment: access control SFP(s) and/or information flow control SFP(s)] 
when importing user data, controlled under the SFP, from outside of the TSC. 

10.7.5.2 FDPJTC.I. 2 

The TSF shall ignore any security attributes associated with the user data when imported from outside 
the TSC. 

10.7.5.3 FDPJTC.1.3 

The TSF shall enforce the following rules when importing user data controlled under the SFP from 
outside the TSC: [assignment: additional importation control rules]. 
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10.7.6 FDPJTC.2 Import of user data with security attributes 

Hierarchical to: No other components. 
Dependencies: [FDP_ACC.1 Subset access control, or 

FDP_IFC.1 Subset information flow control] 

[FTPJTC.1 inter-TSF trusted channel, or 

FTP_TRP.1 Trusted path] 

FPT_TDC.1 Inter-TSF basic TSF data consistency 

10.7.6.1 FDPJTC.2.1 

The TSF shall enforce the [assignment: access control SFP and/or information flow control SFP] when 
importing user data, controlled under the SFP, from outside of the TSC. 

10.7.6.2 FDPJTC.2.2 

The TSF shall use the security attributes associated with the imported user data. 

tO.7.6.3 FDPJTC.2.3 

The TSF shall ensure that the protocol used provides for the unambiguous association between the 
security attributes and the user data received. 

10.7.6.4 FDP_ITC.2.4 

The TSF shall ensure that interpretation of the security attributes of the imported user data is as 
intended by the source of the user data. 

10.7.6.5 FDPJTe.2.5 

The TSF shall enforce the following rules when importing user data controlled under the SFP from 
outside the TSC: [assignment: additional importation control rules]. 

10.8 InternalTOE transfer (FDPJTT) 

10.8.1 Family Behaviour 

This family provides requirements that address protection of user data when It is transferred between parts of 
a TOE across an internal channel. This may be contrasted with the Inter-TSF user data confidentiality transfer 
protection (FDP_UCT) and Inter-TSF user data integrity transfer protection (FDP_UIT) families, which provide 
protection for user data when it is transferred between distinct TSFs across an external channel, and Export to 
outside TSF control (FDP_ETC) and Import from outside TSF control (FDPJTC), which address transfer of 
data to or from outside the TSF's control. 

10.8.2 Component levelling 



roP ITT: Litemal TOE transfer 
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Figure 30 - FDPJTT component levelling 
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FDP_ITT.1 Basic internal transfer protection, requires that user data be protected when transmitted between 
parts of the TOE. 

FDP_ITT.2 Transmission separation by attribute, requires separation of data based on the value of SFP- 
relevant attributes in addition to the first component. 

FDP_ITT.3 Integrity monitoring, requires that the SF monitor user data transmitted between parts of the TOE 
for identified integrity errors. 

FDP_ITT.4 Attribute-based integrity monitoring expands on the third component by allowing the form of 
integrity monitoring to differ by SFP-relevant attribute. 

10.8.3 Management of FDPJTT.1, FDPJTT.2 

The following actions could be considered for the management functions in FMT: 

a) If the TSF provides multiple methods to protect user data during transmission between physically 
separated parts of the TOE. the TSF could provide a pre-defined role with the ability to select the method 
that will be used. 

10.8.4 Management of FDPJTT.3, FDPJTT.4 

The following actions could be considered for tlie management functions in FMT: 

a) The specification of the actions to be taken upon detection of an integrity error could be configurable. 

10.8.5 Audit of FDPJTT.1, FDPJTT.2 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 

a) Minimal: Successful transfers of user data, including identification of the protection method used. 

b) Basic: All attempts to transfer user data, including the protection method used and any errors that 
occurred. 

10.8.6 Audit of FDPJTT.3, FDPJTT.4 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 

r r /o I : 

a) Minimal: Successful transfers of user data, including identifrcation of the integrity protection method used. 

b) Basic: All attempts to transfer user data, including the integrity protection method used and any errors 
that occurred. 

c) Basic: Unauthorised attempts to change the integrity protection method. 

d) Detailed; The action taken upon detection of an integrity error. 

10.8.7 FDPJTT.1 Basic internal transfer protection 
Hierarchical to: No other components. 
Dependencies: [FDP_ACC.1 Subset access control, or 

FDP_IFC.1 Subset information flow control] 
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10.8.7.1 FDPJTT.1.1 

The TSF shall enforce the [assignment: access control SFP(s) and/or information flow control $FP(s)] 
to prevent the [selection: disclosure, modification, loss of use] of user data when it is transmitted 
between physically-separated parts of the TOE. 

10.8.8 FDP_ITT.2 Transmission separation by attribute 

Hierarchical to: FDPJTT.1 Basicinternai transfer protection 

Dependencies: [FDP_ACC.1 Subset access control, or 

FDP_IFC.1 Subset Information flow control] 

10.8.8.1 FDPJTT.2.1 

The TSF shall enforce the [assignment: access control SFP(s) and/or information flow control SFP(s)] to 
prevent the [selection: disclosure, modification, loss of use] of user data when it is transmitted between 
physicalfy-separated parts of the TOE. 

1X).8.8.2 FDPJTT.2.2 

The TSF shall separate data controlled by the SFP(s) when transmitted between physically-separated 
parts of the TOE, based on the values of the following: [assignment: security attributes that require 
separation], 

10.8.9 FDPJTT.S Integrity monitoring 

Hierarchical to: No other components. 
Dependencies: [FDP_ACC.1 Subset access control, or 

FDP_IFC.1 Subset information flow control] 

FDP^ITT.1 Basic internal transfer protection 

10.8.9.1 FDPJTT.3.1 

The TSF shall enforce the [assignment: access control SFP(s} and/or information flow control SFP(s)] 
to monitor user data transmitted between physically-separated parts of the TOE for the following 
errors: [assignment: integrity errors]. 

10.8.9.2 FDPJTT.3.2 

Upon detection of a data integrity error, the TSF shall [assignment: specify the action to be talten 
upon integrity error]. 

10.8.10 FDPJTT.4 Attribute-based integrity monitoring 

Hierarchical to: FDP_ITT.3 Integrity monitoring 
Dependencies: [FDP_ACC.1 Subset access control, or 

FDP_IFC.1 Subset information flow control] 

FDP_ITT.2 Transmission separation by attribute 
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10.8.10.1 FDP nT.4.1 



The TSF shall enforce the [assignment: access control SFP(s) and/or information flow control SFP(s)] to 
monitor user data transmitted between physically-separated parls of the TOE for the following errors: 
[assignment: integrity errors], based on the following attributes: [assignment: security attributes that 
require separate transmission channels]. 

10.8.10.2 FDPJTT.4.2 

Upon detection of a data integrity error, the TSF shall [assignment: specify the action to be tal<en upon 
integrity ernDi]. 

10.9 Residual information protection (FDP_RIP) 

10.9.1 Family Behaviour 

This family addresses the need to ensure that deleted information is no longer accessible, and that newly 
created objects do not contain information that should not be accessible. This family requires protection for 
information that has been logically deleted or released, but may still be present within the TOE. 

10.9.2 Component levelling 



FDP_RF-. Residual itifonnation protection 



Figure 31 - FDP_R!P component levelling 

FDP_R!P.1 Subset residual information protection, requires that the TSF ensure that any residual information 
content of any resources Is -unavailable to a defined subset of the objects in the TSC upon the resource's 
allocation or deallocation. 

FDP_RIP.2 Full residual information protection, requires that the TSF ensure that any residual information 
content of any resources is unavailable to all objects upon the resource's allocation or deallocation. 

10.9.3 Management of FDP_RIP.1, FDP_RIP.2 

The following actions could be considered for the management functions In FMT: 

a) The choice of when to perform residual information protection {i.e. upon allocation or deallocation) could 
be made configurable within the TOE. 

10.9.4 Audit of FDP_RIP.1, FDP_RIP.2 

There are no auditable events foreseen. 

10.9.5 FDP_RIP.1 Subset residual information protection 
Hierarchical to: No other components. 
Dependencies: No dependencies. 

10.9.5.1 FDP_RIP.1.1 

The TSF shall ensure that any previous information content of a resource is made unavailable upon 
the [selection: allocation of the resource to, deallocation of the resource from] the following objects- 
[assignment: //sf of oAyects]. 
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10.9,6 FDP_RIP.2 Full residual information protection 

Hierarchical to: FDP_RIP.1 Subset residual information protection 

Dependencies: No dependencies. 

10.9.6.1 FDP_RIP.2.1 

Tlie TSF shall ensure that any previous information content of a resource is made unavailable upon the 
[selection: allocation of the resource to, deallocation of the resource from] all objects. 

10.10 Rollback (FDP_ROL) 

10.10.1 Family Behaviour 

The rollback operation involves undoing the last operation or a series of operations, bounded by some limit, 
such as a period of time, and return to a previous known state. Rollback provides the ability to undo the 
effects of an operation or series of operations to preserve the integrity of the user data. 

10.10.2 Component levelling 



FDP ROLrRoliback 



Figure 32 - FDP_ROL component levelling 

FDP_R0L.1 Basic rollback addresses a need to roll back or undo a limited number of operations within the 
defined bounds. 

FDP_R0L.2 Advanced rollback addresses the need to roll back or undo all operations within the defined 
bounds. 

10.10.3 Management of FDP_R0L.1, FDP_R0L.2 

The following actions could be considered for the management functions in FMT: 

a) The boundary limit to which rollback may be performed could be a configurable item within the TOE. 

b) Permission to perform a rollback operation could be restricted to a well defined role. 

10.10.4 Audit of FDP_R0L.1,FDP_R0L2 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: All successful rollback operations. 

b) Basic: All attempts to perform rollback operations. 

c) Detailed: All attempts to perform rollback operations, including identification of the types of operations 
rolled back. 

10.10.5- FDP_R0L.1 Basic rollback 

Hierarchical to: No other components. 
Dependencies: [FDP_ACC.1 Subset access control, or 

FDPJFC.1 Subset information flow control] 
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10.10.5.1 FDP ROL.1.1 



The TSF shall enforce [assignment: access control SFP(s) and/or information flow control SFP(s)] to 
permit the rollback of the [assignment: list of operations] on the [assignment: information and/or list 
of objects]. 

10.10.5.2 FDP_ROL.1.2 

The TSF shall permit operations to be rolled back within the [assignment: boundary limit to which 
rollback may be performed]. 

10.10.6 FDP_R0L2 Advanced rollback 

Hierarchical to: FDP_R0L.1 Basic rollback 
Dependencies: [FDP_ACC.1 Subset access control, or 

FDPJFC.1 Subset information flow control] 

10.10.6.1 FDP_R0L.2.1 

The TSF shall enforce [assignment: access control SFP(s) and/or information flow control SFP(s)] to permit 
the rollback of all the operations on the [assignment: list of objects]. 

10.10.6.2 FDP_ROL.2.2 

The TSF shall permit operations to be rolled back within the [assignment: boundary limit to which rollback may 
be performed\. 

10.11 Stored data integrity (FDP_SDI) 

10.11.1 Family Behaviour 

.This family provides requirements that address protection of user data while it is stored within the TSC. 
Integrity errors may affect user data stored in memory, or in a storage device. This family differs from Internal 
TOE transfer (FDPJTT) which protects the user data from integrity errors while being transferred within the 
TOE. 

10.11.2 Component levelling 



FDP SDl: Stored data integrity 



Figure 33 - FDP_SDi component levelling 

FDP_SDI.1 Stored data integrity monitoring, requires that the SF monitor user data stored within the TSC for 
identified integrity errors. 

FDP_SDI.2 Stored data integrity monitoring and action adds the additional capability to the first component by 
allowing for actions to be taken as a result of an error detection. 

10.11.3 Management of FDP_SDI.1 

There are no management activities foreseen. 



49 



IS 14990 (Part 2): 2006 
ISO/IEC 15408-2: 2005 

10.11.4 Management of FDP_SDI.2 

The following actions could be considered for the management functions in FMT: 

a) The actions to be taken upon the detection of an integrity error could be configurable. 

10.11 .5 Audit of FDP_SDI.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: Successful attempts to check the integrity of user data, including an indication of the results oT 
the check. 

b) Basic: All attempts to check the integrity of user data, including an indication of the results of the check, if 
performed. 

c) Detailed: The type of integrity error that occurred. 

10.11.6 Audit of FDP_SDI.2 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 

PP/ST: 

a) Minimal: Successful attempts to check the integrity of user data, including an indication of the results of 
the check. 

b) Basic: All attempts to check the integrity of user data, including an indication of the results of the check, if 
performed. 

c) Detailed: The type of integrity error that occurred. 

d) Detailed: The action taken upon detection of an integrity error. 

10.11.7 FDP_SDI.1 Stored data integrity monitoring 
Hierarchical to: No other components. 
Dependencies: No dependencies. 

10.11.7.1 FDP_SDI.1.1 

Tlie TSF shall monitor user data stored within the TSC for [assignment: integrity errors] on ail objects, 
based on tiie following attributes: [assignment: user data attributes]. 

tO.1 1 .8 FDP_SDi.2 Stored data integrity monitoring and action 

Hierarchical to: FDP_SDI.1 Stored data integrity monitoring 
Dependencies: No dependencies. 

10.11.8.1 FDP_SDI.2.1 

The TSF shall monitor user data stored within the TSC for [assignment: integrity errors] on all objects, based 
on the following attributes: [assignment: user data attributes]. 

10.11.8.2 FDP_SDI.2.2 

Upon detection of a data integrity error, the TSF shall [assignment: action to be talten]. 
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10.12 Inter-TSF user data confidentiality transfer protection {FDP_UCT) 

10.12.1 Family Behaviour 

This family defines the requirements for ensuring the confidentiality of user data when it is transferred using 
an external channel between distinct TOEs or users on distinct TOEs. 

10.12.2 Component levelling 



FDP_UCT: Inter-TSF user data confidentiality transfer protection 



Figure 34 - FDP_UCT component levelling 

In FDP_UCT.1 Basic data exchange confidentiality, the goal is to provide protection from disclosure of user 
data while in transit. 

1 0.1 2.3 Management of FDP_UCT.1 

There are no management activities foreseen. 

10.12.4 Audit of FDP_UCT.1 

The following actions should be audttable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: The identity of any user or subject using the data exchange mechanisms. 

b) Basic: The identity of any unauthorised user or subject attempting to use the data exchange mechanisms. 

c) Basic: A reference to the names or other indexing information useful in identifying the user data that was 
transmitted or received. This could include security attributes associated with the information. 

10.12.5 FDP_UCT.1 Basic data exchange confidentiality 

Hierarchical to: No other components. 

Dependencies: [FTPJTC.1 Inter-TSF trusted channel, or 

FTP_TRP.1 Trusted path] 

[FDP_ACC.1 Subset access control, or 

FDP_IFC.1 "Subset information flow control] 
10.12.5.1 FDP_UCT.1.1 

The TSF shall enforce the [assignment: access control SFP(s) and/or information flow control SFP(sJ\ 
to be able to [selection: transmit, receive] objects in a manner protected from unauthorised disclosure. 

10.13 Inter-TSF user data integrity transfer protection (FDP_UIT) 

10.13.1 Family Behaviour 

This family defines the requirements for providing integrity for user data in transit between the TSF and 
another trusted IT product and recovering from detectable errors. At a minimum, this family monitors the 
integrity of user data for modifications. Furthermore, this family supports different ways of correcting detected 
integrity errors. 
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10.13.2 Component levelling 



FDP UIT: ]nter-TSF user data integrity transfer protection 



Figure 35 - FDP_UIT component levelling 

FDP_U!T.1 Data exchange integrity addresses detection of modifications, deletions, Insertions, and replay 
errors of the user data transmitted. 

FDP_UIT.2 Source data exchange recovery addresses recovery of the original user data by the receiving TSF 
with help from the source trusted IT product. 

FDP_UIT.3 Destination data exchange recovery addresses recovery of the original user data by the receiving 
TSF on its own without any help from the source trusted IT product. 

10.13.3 Management of FDP_U1T.1, FDP_UIT.2, FDP_U1T.3 

There are no management activities foreseen. 

10.13.4 Audit of FDP_UIT.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 

PP/ST: 

a) Minimal: The identity of any user or subject using the data exchange mechanisms. 

b) Basic: The identity of any user or subject attempting to use the user data exchange mechanisms, but who 
is unauthorised to do so. 

c) Basic: A reference to the names or other indexing information useful in identifying the user data that was 
transmitted or received. This could include security attributes associated with the user data. 

d) Basic: Any identified attempts to block transmission of user data. 

e) Detailed: The types and/or effects of any detected modifications of transmitted user data. 

10.13.5 Audit of FDP_UIT.2, FDP_UIT.3 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: The identity of any user or subject using the data exchange mechanisms. 

b) Minimal: Successful recovery from errors including they type of error that was detected. 

c) Basic: The identity of any user or subject attempting to use the user data exchange mechanisms, but who 
is unauthorised to do so. 

d) Basic: A reference to the names or other indexing information useful in identifying the user data that was 
transmitted or received. This could include security attributes associated with the user data. 

e) Basic: Any identified attempts to block transmission of user data. 

f) Detailed: The types and/or effects of any detected modifications of transmitted user data. 
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10.13.6 FDP_UIT.1 Data exchange integrity 

Hierarchical to: No other components. 

Dependencies: [FDP_ACC.1 Subset access control, or 

FDPJFd Subset information flow control) 

[FTP_ITC.1 Inter-TSF trusted channel, or 

FTP_TRP.1 Trusted path] 

10.13.6.1 FDP_UIT.1.1 

The TSF shall enforce the [assignment: access control SFP(s) and/or information flow control SFP(sJl 
to be able to [setection: transmit, receive] user data in a manner protected from [selection: 
modification, deletion, insertion, replay] errors. 

10.13.6.2 FDP_UIT.1.2 

The TSF shall be able to deteitnine on receipt of user data, whether [setection: modiTication, deletion, 
insertion, replay] has occurred. 

10.13.7 FDP_UIT.2 Source data exchange recovery 

Hierarchical to: No other components. 
Dependencies: [FDP_ACC.1 Subset access control, or 

FDPJFC.I Subset information flow control] 

[FDP_U1T.1 Data exchange integrity, or 

FTPJTC.1 Inter-TSF trusted channel] 

10.13.7.1 FDP_UIT.2.1 

The TSF shall enforce the [assignment: access control SFP(s) and/or information flow control SFP(s)] 
to be able to recover from [assignment: list of recoverable errors] with the help of the source trusted 
IT product. 

10.13.8 FDP_UIT.3 Destination data exchange recovery 

Hierarchical to: FDP_UiT.2 Source data exchange recovery 
Dependencies: [FDP_ACC.1 Subset access control, or 

FDPJFd Subset information flow control] 

[FDP_UIT.1 Data exchange integrity, or 

FTPJTC.I Inter-TSF trusted channel] 

10.13.8.1 FDP_UIT.3.1 

The TSF shall enforce the [assignment: access control SFP(s) and/or information flow control SFP(s)] to be 
able to recover from [assignment: list of recoverable errom] without any help from the source trusted IT 
product. 
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1 1 Class FIA: Identification and authentication 

Families in this class address the requirements for functions to establish and verily a claimed user identity. 

Identification and Authentication is required to ensure that users are associated with the proper security 
attributes (e.g. identity, groups, roles, security or integrity levels). 

The unambiguous identification of authorised users and the correct association of security attributes with 
users and subjects is critical to the enforcement of the intended security policies. The families in this class 
deal with determining and verifying the identity of users, determining their authority to interact with the TOE, 
and with the correct association of security attributes for each authorised user. Other classes of requirements 
(e.g. User Data Protection, Security Audit) are dependent upon correct identification and authentication of 
users in order to be effective. 



FIA AFL: Authentication faihires 



FIA ATD: User attribute definition 



F1A__S0S: Specification of secrets 



FIA UAU: User authentication 



FIA UID; User identification 



F1A_USB: User-subject binding 




Frgure 36 - FIA: identification and authentication class decomposition 

11.1 Authentication failures (FIA_AFL) 

11.1.1 Family Behaviour 

This family contains requirements for defining values for some number of unsuccessful authentication 
attempts and TSF actions in cases of authentication attempt failures. Parameters include, but are not limited 
to, the number of failed authentication attempts and time thresholds. 
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11.1.2 Component levelling 



FIA AFL: Authentication failures 



Figure 37 - FIA_AFL component levelling 

FIA_AFL.1 Authentication failure liandiing, requires that the TSF be able to terminate the session 
establishment process after a specified number of unsuccessful user authentication attempts. It also requires 
that, after termination of the session establishment process, the TSF be able to disable the user account or 
the point of entry (e.g. workstation) from which the attempts were made until an administrator-defined 
condition occurs. 

11.1.^ Management of FIA_AFL1 

The following actions could be considered for the management functions in FMT: 

a) management of the threshold for unsuccessful authentication attempts; 

b) management of actions to be taken in the event of an authentication failure. 

11.1.4 Audit of FIA_AFL.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: the reaching of the threshold for the unsuccesful authentication attempts and the actions (e.g. 
disabling of a terminal) taken and the subsequent, if appropriate, restoration to the normal state (e.g. re- 
enabling of a terminal). 

11.1.5 FIA_AFL.1 Authentication failure handling 

Hierarchical to: No other components. 
Dependencies: FIA_UAU.1 Timing of authentication 

11.1.5.1 FIA_AFU1.1. 

The TSF shall detect when [selection: [assignment: positive integer number], an administrator 
configurable positive integer within[assignment: range of acceptable valuesj\ unsuccessful 
authentication attempts occur related to [assignment: list of authentication events]. 

11.1.5.2 FIA_AFL.1.2 

When the defined number of unsuccessful authentication attempts has been met or surpassed, the 
TSF shall [assignment: //st of actions]. 

11.2 User attribute definition (FIA.ATD) 

11.2.1 Family Behaviour 

All authorised users may have a set of security attributes, other than the user's identity, that is used to enforce 
the TSF. This family defines the requirements for associating user security attributes with users as needed to 
support the TSP. 
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11.2.2 Component levelling 



FIA ATD: User attribfute definition 



Figure 38 - FIA_ATD component levelling 

FIA_ATD.1 User attribute definition, allows user security attributes for each user to be maintained individually. 

1 1 .2.3 Management of FIA_ATD.1 

The foltowing actions eoufd be considered for the management functions in FMT: 

a) If so Indicated in the assignment, the authorised administrator might be able to define additional security 
attributes for users. 

11 .2.4 Audit of FIA_ATD.1 

There are no audltable events foreseen. 

11.2.5 FIA_ATD.1 User attribute definition 

Hierarchical to: No other components. 

Dependencies: No dependencies. 

11.2.5.1 FIA_ATD.1.1 

The TSF shall maintain the following list of security attributes belonging to individual users: 
[assignment: list of security attributes]. 

11.3 Specification of secrets (FiA_SOS) 

11.3.1 Family Behaviour 

This family defines requirements for mechanisms that enforce defined quality metrics on provided secrets and 
generate secrets to satisfy the defined metric. 

11.3.2 Component levelling 



FIASOS: Specification of secrets 



Figure 39 - FIA_SOS component levelling 

FIA_S0S.1 Verification of secrets, requires the TSF to verify that secrets meet defined quality metrics. 

FIA_S0S.2 TSF Generation of secrets, requires the TSF to be able to generate secrets that meet defined 
quality metrics. 

1 1 .3.3 Management of FtA_S0S.1 

The following actions could be considered for the management functions in FMT: 
a) the management of the metric used to verify the secrets. 
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11.3.4 Management of FIA_SOS.2 

The following actions could be considered for the management functions in FMT: 
a) the marragement of the metric used to generate the secrets. 

1 1 .3.5 Audit of FIA_S0S.1 , FIA_S0S.2 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: Rejection by the TSF of any tested secret; 

b) Basic: Rejection or acceptance by the TSF of any tested secret; 

c) Detailed: Identification of any changes to the defined quality metrics. 

11.3.6 FIA_S0S.1 Verification of secrets 
Hierarchical to: No other components. 
Dependencies: No dependencies. 
11.3.6.1 FIA_S0S.1.1 

The TSF shall provide a mechanism to verify that secrets meet [assignment: a deffned quality metric]. 

11.3.7 FiA_S0S.2 TSF Generation of secrets 
Hierarchical to: No other components. 
Dependencies: No dependencies. 

11.3.7.1 FIA_S0S.2.1 

The TSF shall provide a mechanism to generate secrets that meet [assignment: a defined quality 
metric]. 

11.3.7.2 FiA_SOS.2.2 

The TSF shall be able to enforce the use of TSF generated secrets for [assignment: list of TSF 
functions]. 

11.4 User authentication (FIA_UAU) 
11.4.1 Family Behaviour 

This family defines the types of user authentication mechanisms supported by the TSF. This family also 
defines the required attributes on which the user authentication mechanisms must be based. 
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11.4.2 Component levelling 



FIA UAU: User autheiiticatioii 




Figure 40 - FIA_UAU component levelling 

FIA_UAU.1 Timing of authentication, allows a user to perform certain actions prior to the authentication of the 
user's identity. 

FIA_UAU.2 User authentication before any action, requires that users are authenticated before any action will 
be allowed by the TSF. 

FIA_UAU.3 Unforgeable authentication Unforgeable authentication, requires the authentication mechanism to 
be able to detect and prevent the use of authentication data that has been forged or copied. 

FIA_UAU.4 Single-use authentication mechanisms, requires an authentication mechanism that operates with 
single-use authentication data.' 

FtA_UAU.5 Multiple authentication mechanisms, requires that different authentication mechanisms be 
provided and used to authenticate user identities for specific events. 

FIA_UAU.6 Re-authenticating, requires the ability to specify events for which the user needs to be re- 
authenticated. 

FIA_UAU.7 Protected authentication feedback, requires that only limited feedback information is provided to 
the user during the authentication. 

11.4.3 Management of FtA_UAU.1 

The following actions could be considered for the management functions in FMT: 

a) management of the authentication data by an administrator; 

b) management of the authentication data by the associated user; 

c) managing the list of actions that can be taken before the user is authenticated. 

11.4.4 IManagementof FIA_UAU.2 

The following actions could be considered for the management functions in FMT: 

a) management of the authentication data by an administrator; 

b) management of the authentication data by the user associated with this data. 
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11.4.5 Management of FIA_UAU.3, FIA_UAU.4, FIA_UAU.7 

There are no management activities foreseen. 

1 1 .4.6 Management of FIA_UAU.5 

The following actions could be considered for the management functions in FMT: 

a) the management of authentication mechanisms; 

b) the management of the rules for authentication. 

1 1 .4.7 Management of FIA_UAU.6 

The following actions could be considered for the management functions in FMT: 

a) if an authorised administrator could request re-authentication, the management includes a re- 
authentication request. 

11.4.8 Audit of FIA_UAU.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: Unsuccessful use of the authentication mechanism; 

b) Basic: All use of the authentication mechanism; 

c) Detailed: All TSF mediated actions performed before authentication of the user. 

11.4.9 Audit of FIA_UAU.2 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: Unsuccessful use of the authentication mechanism; 

b) Basic: All use of the authentication mechanism. 

1 1 .4.1 Audit of FIA_U AU.3 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 

a) Minimal: Detection of fraudulent authentication data; 

b) Basic: All immediate measures taken and results of checks on the fraudulent data. 

11.4.11 Audit of FIA_UAU.4 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 

a) Minimal: Attempts to reuse authentication data. 
11A12 Audit of FIA_UAU.5 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: The final decision on authentication; 

b) Basic: The result of each activated mechanism together with the final decision. 
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11.4.13 Audit Of FIA_UAU.6 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: Failure of reauthentication; 

b) Basic: All reauthentication attempts. 

1 1 .4.14 Audit of FIA_UAU.7 

There are no auditable events foreseen. 

11.4.15 FtA_UAU.1 Timing of authentication 
Hierarchical to: No other components. 
Dependencies: FIA_UID.1 Timing of identification 

11.4.15.1 FIA_UAU.1.1 

The TSF shall allow [assignment: list of TSF mediated actions] on behalf of the user to be performed 
before the user is authenticated. 

11.4.15.2 FIA_UAU.1.2 

The TSF shall require each user to be successfully authenticated before allowing any other TSF- 
mediated actions on behalf of that user. 

1 1 .4.1 6 FIA_UAU.2 User authentication before any action 

Hierarchical to: FIA_UA' 1.1 Timing of authentication 

Dependencies: FIA_UID.1 Timing of identification 

11.4.16.1 FIA_UAU.2.1 

The TSF shall require each user to be successfully authenticated before allowing any other TSF- 
mediated actions on behalf of that user. 

11.4.17 FIA_UAU.3 Unforgeable authentication 

Hierarchical to: No other components. 
Dependencies: No dependencies. 

11.4.17.1 FIA_UAU.3.1 

The TSF shall [selection: detect, preven(\ use of authentication data that has been forged by any user 
of the TSF. 

11.4.17.2 FIA_UAU.3.2 

The TSF shall [selection: detect, prevent] use of authentication data that has been copied from^ny 
other user of the TSF. 



60 



IS 14990 (Part 2): 2006 
ISO/IEC 15408-2: 2005 

1 1 .4.1 8 FIA_UAU.4 Single-use authentication mechanisms 

Hierarchical to: No other components. 
Dependencies: No dependencies. 
11.4.18.1 FIA_UAU.4.1 

The TSF shall prevent reuse of authentication data related to .[assignment: identified authentication 
mechanism(s}]. 

11.4.19 FIA_UAU.5 Multiple authentication mechanisms 

Hierarchical to; No other components. 
Dependencies: No dependencies. 

11.4.19.1 FIA_UAU.5.1 

The TSF shall provide [assignment: list of multiple authentication mechanisms] to support user 
authentication. 

11.4.19.2 FIA_UAU.5.2 

The TSF shall authenticate any user's claimed identity according to the [assignment: rules describing 
how the multiple authentication mechanisms provide authentication], 

11.4.20 FIA_UAU.6 Re-authenticating 

Hierarchical to: No other components. 
Dependencies: No dependencies. 
11.4.20.1 FIA_UAU.6.1 

The TSF shall re-authenticate the user under the conditions [assignment: list of conditions under 
which re-authentication is required]. 

11.4.21 FIA_UAU.7 Protected authentication feedbacli 

Hierarchical to: No other components. 

Dependencies: FIA_UAU.1 Timing of authentication 

11.4.21.1 FIA_UAU.7.1 

The TSF shall provide only [assignment: list of feedback] to the user while the authentication is in 
progress. 

11.5 User identification (FIA_UID) 

11.5.1 Family Behaviour 

This family defines the conditions under which users shall be required to identify themselves before 
performing any other actions that are to be mediated by the TSF and which require user identification. 
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11.5.2 Component levelling 



FIA UID: User identification 



Figure 41 - FIA_UID component levelling 

FIA_UID.1 Tinning of identification, allows users to perform certain actions before being identified by the TSF. 

FIA_UID.2 User identification before any action, requires that users identify themselves before any action will 
be allowed by the TSF. 

11.5.3 Management of FIA_UID.1 

The following actions could be considered for the management functions in FMT: 

a) the management of the user identities; 

b) if an authorised administrator can change the actions allowed before identification, the managing of the 
action lists. 

11.5.4 Management of FIA_UID.2 

The following actions could be considered for the management functions in FMT: 
a) the management of the user identities. 

11.5.5 Audit of FIA_UID.1, FIA_UID.2 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: Unsuccessful use of the user identification mechanism, including the user identity provided; 

b) Basic: All use of the user identification mechanism, including the user identity provided. 

11.5.6 FIA_UID.1 Timing of identification 
Hierarchical to: No other components. 
Dependencies: No dependencies. 

11.5.6.1 FtA_UID.1.1 

The TSF shall allow [assignment: list of TSF-mediated actions] on behalf of the user to be performed 
before the user Is identified. 

11.5.6.2 FIA_UID.1.2 

The TSF shall require each user to be successfully identified before allowing any other TSF-mediated 
actions on behalf of that user. 

11.5.7 FIA_UID.2 User identification before any action 

Hierarchical to: FIA_UID.1 Timing of identification 
Dependencies: No dependencies. 
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11.5.7.1 FIA UID.2.1 



The TSF shall require each user to identify itself before allowing any other TSF-mediated actions on 
behalf of that user. 

11.6 User-subject binding (FIA_USB) 

11.6.1 Family Behaviour 

An authenticated user, in order to use the TOE, typically activates a subject. The user's security attributes are 
associated (totally or partially) with this subject. This family defines requirements to create and maintain the 
association of the user's security attributes to a subject acting on the user's behalf. 

11.6.2 Component levelling 



FLA, USB: User-subject binding 



Figure 42 ~ FIA_USB component levelling 

FIA_USB.1 User-isubject binding, requires the specification of any rules governing the association between 
user attributes and the subject attributes Into which they are mapped. 

11.6.3 Management of FIA_USB.1 

The following actions could be considered for the management functions in FMT: 

a) an authorised administrator can define default subject security attributes. 

b) an authorised administrator can change subject security attributes. 

11.6.4 Audit of FIA_USB.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: Unsuccessful binding of user security attributes to a subject (e.g. creation of a subject). 

b) Basic: Success and failure of binding of user security attributes to a subject (e.g. success or failure to 
create a subject). 

11.6.5 FIA_USB.1 User-subject binding 

Hierarchical to: No other components. 
Dependencies: FIA_ATD.1 User attribute xlefinition 

11.6.5.1 FIA_USB.1.1 

The TSF shall associate the following user security attributes with subjects acting on the behalf of 
that user: [assignment: list of user security attributes]. 

11.6.5.2 FIA_USB.1.2 

The TSF «hali enforce the following rules on the initial association of user security attributes with 
subjects acting on the behalf of users: [assignment: rules for the initial association of attributes]. 
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11.6.5.3 FIA_USB.l3 

The TSF shall enforce the following rules governing changes to the user security attributes associated 
with subjects acting on the behalf of users: [assignment: rules for the changing of attributes], 

12 Class FMT: Security management 

This class is intended to specify the management of several aspects of the TSF: security attributes, TSF data 
and functions. The different management roles and their interaction, such as separation of capability, can be 
specified. 

This class has several objectives: 

a) management of TSF data, which include, for example, banners; 

b) management of security attributes, which include, for example, the Access Control Lists, and Capability 
Lists; 

c) management of functions of the TSF, which includes, for example, the selection of functions, and rules or 
conditions influencing the behaviour of the TSF; 

d) definition of security roles. 



FMTMOF: Management of fiinetions in TSF 



FMT MSA; Management of security attributes 



FMT_MTD: Management of TSF data 



FMT RFV: Revocation 



FMT__S.^E: Security attribute expiiatioii 



FMT_SMF: Specification of Management Functions 



FMTSMR; Security management roles 




Figure 43 - FMT: Security management class decomposition 
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12.1 Management of functions in TSF (FMT_MOF) 

12.1.1 Family Behaviour 

This family allows authorised users control over the management of functions in the TSF. Examples of 
functions in the TSF include the audit functions and the multiple authentication functions. 

12.1.2 Component levelling 



FMT MOF: Management of functions in TSF 



Figure 44 - FMT_MOF component levelling 

FMT_M0F.1 Management of security functions behaviour allows the authorised users (roles) to manage the 
behaviour of functions in the TSF that use rules or have specified conditions that may be manageable. 

12.1.3 Management of FIVIT_M0F.1 

The following actions could be considered for the management functions in FMT: 
a) managing the group of roles that can interact with the functions in the TSF; 

12.1.4 Audit of FMT_M0F.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Basic: All modifications in the behaviour of the functions in the TSF. 

12.1.5 FMT_M0F.1 Management of security functions behaviour 

Hierarchical to: No other components. 

Dependencies; FMT_SMR.1 Security roles 

FMT_SMF.1 Specification of Management Functions 

12.1.5.1 FMT_M0F.1.1 

The TSF shall restrict the ability to [selection: determine the behaviour of, disable, enable, modify the 
behaviour of\ the functions [assignment: list of functions] to [assignment: the authorised identified 
roles]. 

12.2 Management of security attributes (FMT_MSA) 

12.2.1 Family Behaviour 

This family allows authorised users control over the management of security attributes. This management 
might include capabilities for viewing and modifying of security attributes. 
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12.2.2 Component levelling 



FMTMSA: Management of security attributes 




Figure 45 - FMT_MSA component levelling 

FMT_MSA.1 Management of security attributes allows authorised users (roles) to manage the specified 
security attributes. 

FMT_IVISA.2 Secure security attributes ensures that values assigned to security attributes are valid with 
respect to the secure state. 

FMT_MSA.3 Static attribute initialisation ensures that the default values of security attributes are appropriately 
either permissive or restrictive in nature. 

12.2.3 Management of FMT_MSA.1 

The following actions could be considered for the management functions in FMT: 
a) managing the group of roles that can interact with the security attributes. 

12.2.4 Management of FMT_MSA.2 
There are no management activities foreseen. 

12.2.5 Management of FMT_MSA.3 

The following actions could be considered for the management functions in FMT: 

a) managing the group of roles that can specify initial values; 

b) managing the permissive or restrictive setting of default values for a given access control SFP. 

12.2.6 Audit of FMT_MSA.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Basic: All modifications of the values of security attributes. 

12.2.7 Audit Of FMT_MSA.2 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 

PP/ST: 

a) Minimal: All offered and rejected values for a security attribute; 

b) Detailed: All offered and accepted secure values for a security attribute. 
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12.2.8 Audit of FMT MSA.3 



The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Basic: Modifications of the default setting of permissive or restrictive rules. 

b) Basic: All nnodifications of the initial values of security attributes. 

12.2.9 FMT_MSA.1 Management of security attributes 
Hierarchical to: No other components. 
Dependencies: [FDP_ACC.1 Subset access control, or 

FDPJFd Subset information flow control] 
FMT_SMR.1 Security roles 
FMT_SMF.1 Specification of Management Functions 
12.2.91 FMT_MSA.1.1 

The TSF shall enforce the [assignment: access control SFP, information flow control SFP\ to restrict 
the ability to [selection: change_default, query, modify, delete,[assignment: of/ier operationsJ\ the 
security attributes [assignment: list of security attributes] to [assignment: the authorised identified 
roles]. 

12.2.10 FMT_IVISA.2 Secure security attributes 

Hierarchical to: No other components. 

Dependencies: ADV_SPM.1 Informal TOE security policy model 

[FDP_ACC.1 Subset access control, or 

FDPJFC.I Subset information flow control] 

FMT_MSA.1 Management of security attributes 

FMT_SMR.1 Security roles 
12.2.10.1 FMT_MSA.2.1 
The TSF shall ensure that only secure values are accepted for security attributes. 

12.2.11 FMT_MSA.3Static attribute initialisation 
Hierarchical to: No other components. 

Dependencies: FMT_WSA.1 Management of security attributes 

FMT_SMR.1 Security roles 
12.2.11.1 FMT_MSA.3.1 

The TSF shall enforce the [assignment: access control SFP, information flow control SFP] to provide 
[selection, choose one of: restrictive, permissive,[assignment: other property]] default values for 
security attributes that are used to enforce the SFP. 
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12.2.11.2 FMT_MSA.3.2 

The TSF shall allow the [assignment: the authorised identified roles] to specify alternative initial 
values to override the default values when an object or information is created. 

12.3 TVIanagement of TSF data (FMT_MTD) 

12.3.1 Family Behaviour 

This family allows authorised users (roles) control over the management of TSF data. Examples of TSF data 
include audit information, clock, system configuration and other TSF configuration parameters. 

12.3.2 Component levelling 



FMT_MTD: Management of TSF data 




Figure 46 - FMT_MTD component levelling 

FMT_MTD.1 Management of TSF data allows authorised users to manage TSF data. 

FMT_MTD.2 Management of limits on TSF data specifies the action to be taken if limits on TSF data are 
reached or exceeded. 

FMT_MTD.3 Secure TSF data ensures that values assigned to TSF data are valid with respect to the secure 
state. 

12.3.3 Management of FMT_MTD.1 

The following actions could be considered for the management functions in FMT: 
a) managing the group of roles that can interact with the TSF data. 

12.3.4 Management of FMT_MTD.2 

The following actions could be considered for the management functions in FMT: 
a) managing the group of roles that can interact with the limits on the TSF data. 

12.3.5 Management of FMT_MTD.3 
There are no management activities foreseen. 

12.3.6 Audit of FMT_MTD.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Basic: All modifications to the values of TSF data. 
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12.3.7 Audit of FMT mTD.2 



The following actions shoutd be auditabie if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Basic: All modifications to the limits on TSF data; 

b) Basic: All modifications in the actions to be taken in case of violation of the limits. 

12.3.8 Audit Of FMT_MTD.3 

The following actions should be auditabie if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: All rejected values of TSF data. 

12.3.9 FIVIT_MTD.1 Management of TSF data 

Hierarchical to: No other components. 

Dependencies: FMT_SMR.1 Security roles 

FMT_SMF.1 Specification of Management Functions 

12.3.9.1 FMT_MTD.1.1 

The TSF shall restrict the ability to [selection: change_default, query, modify, delete, 
clear,[assignment: other operations]\ the [assignment: list of TSF data] to [assignment: the authorised 
identified roles]. 

12.3.10 FIVIT_MTD.2 Management of limits on TSF data 

Hierarchical to: No other components. 
Dependencies: FMT_MTD.1 Management of TSF data 
FMT_SMR.1 Security roles 

12.3.10.1 FMT_MTD.2.1 

The TSF shall restrict the specification of the limits for [assignment: list of TSF data] to [assignment: 
the authorised identified roles]. 

12.3.10.2 FMT_MTD.2.2 

The TSF shall take the following actions, if the TSF data are at, or exceed, the indicated limits: 
[assignment: actions to be taken]. 

12.3.11 FMT_MTD.3 Secure TSF data 

Hierarchical to: No other components. 

Dependencies: ADV_SPM.1 Informal TOE security policy model 

FMT_MTD.1 Management of TSF data 
12.3.11.1 FMT_MTD.3.1 
The TSF shall ensure that only secure values are accepted for TSF data. 
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12.4 Revocation (FMT_REV) 

12.4.1 Family Behaviour 

This family addresses revocation of security attributes for a variety of entities within a TOE. 

12.4.2 Component levelling 



FMT REV: Revocation 



I 



Figure 47 - FMT_REV component levelling 

FMT_REV.1 Revocation provides for revocation of security attributes to be enforced at some point in time. 

12.4.3 Management of FMT_REV.1 

The following actions could be considered for the management functions in FMT: 

a) managing the group of roles that can invoke revocation of security attributes; 

b) managing the lists of users, subjects, objects and other resources for which revocation is possible; 

c) managing the revocation rules. 

12.4.4 Audit Of FMT_REV.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: Unsuccessful revocation of security attributes; 

b) Basic: All attempts to revoke security attributes. 

12.4.5 FMT_REV.1 Revocation 
Hierarchical to: No other components. 
Dependencies: FMT_SMR.1 Security roles 

12.4.5.1 FMT_REV.1.1 

The TSF shall restrict the ability to revoke security attributes associated with the [selection: users, 
subjects, objects,[assignment: other additional resources]\ within the ISC to [assignment: the 
authorised identified roles]. 

12.4.5.2 FIVIT_REV.1.2 

The TSF shall enforce the rules [assignment: specification of revocation rules]. 
12.5 Security attribute expiration (FMT_SAE) 
12.5.1 Family Behaviour 

This family addresses the capability to enforce time limits for the validity of security attributes. 
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12.5.2 Component levelling 



FMT_SAE: Security attribute expiratron 



Figure 48 - FMT_SAE component levelling 

FMT_SAE.1 Time-limited authorisation provides the capability for an authorised user to specify an expiration 
time on specified security attributes. 

12.5.3 Management of FMT_SAE.1 

The following actions could be considered for the management functions in FI\/IT: 

a) managing the list of security attributes for which expiration is to be supported; 

b) the actions to be tal<en if the expiration time has passed. 

1 2.5.4 Audit of FMT_SAE.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Basic: Specification of the expiration time for an attribute; 

b) Basic: Action taken due to attribute expiration. 

12.5.5 FMT_SAE,1 Time-limited authorisation 
Hierarchical to: No other components. 
Dependencies: FMT_SMR.1 Security roles 

FPT_STM.1 Reliable time stamps 

12.5.5.1 FMT_SAE.1.1 

The TSF shall restrict the capability to specify an expiration time for [assignment: list of security 
attributes for which expiration is to be supportecf\ to [assignment: the authorised identified roles]. 

12.5.5.2 FIVIT_SAE.1.2 

For each of these security attributes, the TSF shall be able to [assignment: list of actions to be taken 
for each security attribute] after the expiration time for the indicated security attribute has passed. 

12.6 Specification of IVIanagement Functions (FMT_SMF) 

12.6.1 Family Behaviour 

This family allows the specification of the management functions to be provided by the TGE. Management 
functions provide TSFI that allow administrators to define the parameters that control the operation of security- 
related aspects of the TOE, such as data protection attributes, TOE protection attributes, audit attributes, and 
identification and authentication attributes. Management functions also include those functions performed by 
an operator to ensure continued operation of the TOE, such as backup and recovery. This family works in 
conjunction with the other components in the FMT: Security management class: the component in this family 
calls out the management functions, and other families in FMT: Security management restrict the ability to use 
these management functions. 
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12.6.2 Component levelling 



FMT_SMF: Specificatron of Management Functions 



Figure 49 - FMT_SMF component levelling 

FMT_SMF.1 Specification of Management Functions requires that the TSF provide specific management 
functions. 

12.6.3 Management of FMT_SMF.1 

There are no management activities foreseen, 

12.6.4 Audit of FMT_SMF.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal; Use of the management functions. 

12.6.5 FMT_SMF.1 Specification of IVIanagement Functions 
Hierarchical to: No other components. 

Dependencies: No dependencies. 

12.6.5.1 FMT_SMF,1.1 

The TSF shall be capable of performing the following security management functions: [assignment: 
list of security management functions to be provided by the TSF^. 

12.7 Security management roles (FMT_SMR) 

12.7.1 Family Betiavlour 

This family is intended to control the assignment of different roles to users. The capabilities of these rotes with 
respect to security management are described in the other families in this class. 

12.7.2 Component levelling 



FMT_SMR: Security management roles 



Figure 50 - FMT„SMR component levelling 

FMT_SMR.1 Security roles specifies the roles with respect to security that the TSF recognises. 

FMT_SMR.2 Restrictions on security roles specifies that in addition to the specification of the roles, there are 
rules that control the relationship between the roles. 

FMT_SMR.3 Assuming roles, requires that an explicit request is given to the TSF to assume a role. 
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12.7.3 Management of FMT_SMR.1 

The following actions could be considered for the management functions in FMT: 
a) managing the group of users that are part of a role. 

12.7.4 Management of FMT_SMR.2 

The following actions could be considered for the management functions in FMT: 

a) managing the group of users that are part of a role; 

b) managing the conditions that the roles must satisfy. 

12.7.5 Management of FMT_SMR.3 

There are no management activities foreseen. 

12.7.6 Audit of FMT_.SMR.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: modifications to the group of users that are part of a role; 

b) Detailed: every use of the rights of a role. 

12.7.7 Audit of FMT_SMR.2 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: modifications to the group of users that are part of a role; 

b) Minimal: unsuccessful attempts to use a role due to the given conditions on the roles; 

c) Detailed: every use of the rights of a role. 

12.7.8 Audit of FMT_^MR.3 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: explicit request to assume a role. 

1 2.7.9 FMT_SMR.1 Security roles 
Hierarchical to: No other components. 
Dependencies: FIA_UID.1 Timing of identification 

12.7.9.1 FMT_SMR.1.1 

The TSF shall maintain the roles [assignment: the authorised identified roles]. 

12.7.9.2 FMT_SMR.1.2 

The TSF shallbe able to associate users with roles. 
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12.7.10 FMT_SMR.2 Restrictions on security roles 

Hierarchical to: FMT_SMR.1 Security roles 
Dependencies: FIA_UID.1 Tinning of identification 

12.7.10.1 FMT_SMR.2.1 

The TSF shall maintain the roles: [assignment: authorised idenWied roles]. 

12.7.10.2 FMT_SMR.2.2 

The TSF shall be able to associate users with roles. 

12.7.10.3 FMT_SMR.2.3 

The TSF shall ensure that the conditions [assignment: conditions for the different roles] are satisfied. 

1 2.7.1 1 FIVIT_SMR.3 Assuming roles 
Hierarchical to: No other components. 
Dependencies: FMT_SMR.1 Security roles 
12.7.11.1 FMT_SMR.3.1 

The TSF shall require an explicit request to assume the following roles: [assignment: the tolesy 

13 Class FPR: Privacy 

This class contains privacy requirements. These requirements provide a user protection against discovery and 
misuse of identity by other users. 



FPRANO ; Anonymity 



FPR PSE. Pseudonymity 



□<^ 



FPR UNL: Unliiikabilitj^ 



FPR IJNO; IJnobservabititv 




Figure 51 - FPR: Privacy class decomposition 
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13.1 Anonymity (FPR_ANO) 

13.1.1 Family Behaviour 

This family ensures that a user may use a resource or service without disclosing the user's identity. The 
requirements for Anonymity provide protection of the user identity. Anonymity is not intended to protect the 
subject identity. 

13.1.2 Component levelling 



F?R_ANO. AHOiiymitj' 



Figure 52 - FPR_ANO component levelling 

FPR_AN0.1 Anonymity, requires that other users or subjects are unable to determine the identity of a user 
bound to a subject or operation. 

FPR_AN0.2 Anonymity without soliciting information enhances the requirements of FPR_AN0.1 Anonymity 
by ensuring that the TSF does not ask for the user identity. 

13.1.3 Management of FPR_AN0.1, FPR_AN0.2 

There are no management activities foreseen. 

13.1.4 Auditor FPR_AN0.1, FPR_AN0.2 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: The invocation of the anonymity mechanism. 

13.1.5 FPR_AN0.1 Anonymity 

Hierarchical to: No other components. 

Dependencies: No dependencies. 

13.1.5.1 FPR_AN0.1.1 

The TSF shall ensure that [assignment: set of users and/or subjectsl are unable to determine the real 
user name bound to [assignment: list of subjects and/or operations and/or objects]. 

13.1.6 FPR_AN0.2 Anonymity without soliciting information 

Hierarchical to: FPR_AN0.1 Anonymity 
Dependencies: No dependencies. 

13.1.6.1 FPR_AN0.2.1 

The TSF shall ensure that [assignment: set of users and/or subjects] are unable to determine the real user 
name bound to [assignment: list of subjects and/or operations and/or objects]. 

13.1.6.2 FPR_AN0.2.2 

The TSF shall provide [assignment: list of services] to [assignment: list of subjects] without soliciting 
any reference to the real user name. 
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13.2 Pseudoirymity {FPR_PSE) 

13.2.1 Family Behaviour 

This family ensures that a user may use a resource or service without disclosing its user identity, but can still 
be accountable for that use. 

13.2.2 Component levelling 



FPR PSE: Pseiidotivmitv 



2 
3 



Figure 53 - FPR_PSE component levelling 

FPR_PSE.1 Pseudonymity requires that a set of users and/or subjects are unable to determine the identity of 
a user bound to a subject or operation, but that this user is still accountable for its actions. 

FPR_PSE.2 Reversible pseudonymity, requires the TSF to provide a capability to determine the original user 
identity based on a provided alias. 

FPR_PSE.3 Alias pseudonymity, requires the TSF to follow certain construction rules for the alias to the user 
identity. 

13.2.3 Management of FPR_PSE.1, FPR_PSE.2, FPR_PSE.3 

There are no management activities foreseen. 

13.2.4 Audit of FPR„PSE.1, FPR_PSE.2, FPR_PSE.3 

The following actions should be auditabie if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: The subject/user that requested resolution of the user identity should be audited. 

13.2.5 FPR_PSE.1 Pseudonymity 
Hierarchical to: No other components. 
Dependencies: No dependencies. 

13.2.5.1 FPR_PSE.1.1 

The TSF shall ensure that [assignment: set of users and/or subjects] are unable to determine the real 
user name bound to [assignment: list of subjects and/or operations and/or objects]. 

13.2.6.2 FPR„PSE.1.2 

The TSF shall be able to provide [assignment: number of aliases] aliases of the real user name to 
[assignment: list of subjects]. 

13.2.5.3 FPR_PSE.1.3 

The TSF shall [selection, choose one of: determine an alias for a user, accept the alias from the usei^ 
and verify that it conforms to the [assignment: alias metric]. 
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13.2.6 FPR_PSE.2 Reversible pseudonymlty 

Hierarchical to: FPR_PSE.1 Pseudonymity 
Dependencies: FIA_UID.1 Timing of identification 

13.2.6.1 FPR_PSE.2.1 

The TSF shall ensure that [assignment: set of users and/or subjects] are unable to determine the real user 
name bound to [assignment: list of subjects and/or operations. and/or objects]. 

13.2.6.2 FPR_PSE.2.2 

The TSF shall be able to provide [assignment: number of aliases] aliases of the real user name to 
[assignment: list of subjects]. 

13.2.6.3 FPR_PSE.2.3 

The TSF shall [selection, choose one of: determine an alias for a user, accept the alias from the user] and 
verify that it conforms to the [assignment: alias metric]. 

13.2.6.4 FPR_PSE.2.4 

The TSF shall provide [selection: an authorised user,[assignment: list of trusted subjects]] a capability 
to determine the user identity based on the provided alias only under the following [assignment: list of 
condi^ons]. 

13.2.7 FPR_PSE.3 Alias pseudonymity 

Hierarchical to: FPR_PSE.1 Pseudonymity 
Dependencies: No dependencies. 

13.2.7.1 FPR_PSE.3.1 

The TSF shall ensure that [assignment: set of users and/or subjects] are unable to determine the real user 
name bound to [assignment: list of subjects and/or operations and/or objects]. 

13.2.7.2 FPR_PSE.3.2 

The TSF shall be able to provide [assignment: number of aliases] aliases of the real user name to 
[assignment: list of subjects]. 

13.2.7.3 FPR_PSE.3.3 

The TSF shall [selection, choose one of: detemriine an alias for a user, accept the alias from the user] and 
verify that it conforms to the [assignment: alias metric]. 

13.2.7.4 FPR_PSE.3.4 

The TSF shall provide an alias to the real user name which shall be identical to an alias provided 
previously under the following [assignment: list of conditions] otherwise the alias provided shall be 
unrelated to previously provided aliases. 
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13.3 Untinkabiiity (FPR.UNL) 
13.3.1 Family Behaviour 



This family ensures that a user may make multiple uses of resources or services without others being able to 
link these uses together. 

13.3.2 Component levelling 



FPR^^L: L'n'inkability 



Figure 54 - FPR_UNL component levelling 

FPR_UNL.1 Unilnkabllity, requires that users and/or subjects are unable to determine whether the same user 
caused certain specific operations in the system, 

13.3.3 Management Of FPR_UNL.1 

The following actions could be considered for the management functions in FMT: 
a) the management of the unlinkability function 

13.3.4 Audit of FPR_UNL.1 

The following actions should be auditable if FAU_GEN Security audit data generation Is included in the 
PP/ST: 

a) Minimal; The invocation of the unlinkability mechanism. 

13.3.5 FPR_UNL.1 Unl'mkability 

Hierarchical to: No other components. 

Dependencies: No dependencies. 

13.3.5.1 FPR_UNL.1.1 

The TSF shall ensure that [assignment: SBi of users and/or subjects] are unable to determine whether 
[assignment: list of operations][select\on: were caused by the same user, are related as 
follows[assignment: list of relations]]. 

13.4 Unobservability (FPR_UNO) 

13.4.1 Family Behaviour 

This family ensures that a user may use a resource or service without others, especially third parties, being 
able to observe that the resource or service is being used. 
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13.4.2 Component levelling 



FPR_UNO: Unobservability 




Figure 55 - FPR_UNO component levelling 

FPR_UN0.1 Unobservability, requires that users and/or subjects cannot determine wiiether an operation is 
being performed. 

FPR_UN0.2 Allocation of information impacting unobservability. requires that the TSF provide specific 
mechanisms to avoid the concentration of privacy related information within the TOE. Such concentrations 
might impact unobservability if a security compromise occurs. 

FPR_UN0.3 Unobservability without soliciting information.q requires that the TSF does not try to obtain 
privacy related information that might be used to compromise unobservability. 

FPR_UN0.4 Authorised user observability, requires the TSF to provide one or more authorised users with a 
capability to observe the usage of resources and/or services. 

13.4.3 Management of FPR_UN0.1, FPR_UN0.2 

The following actions could be considered for the management functions in FMT: 
a) the management of the behaviour of the unobservability function. 

13.4.4 Management of FPR_UN0.3 

There are no management activities foreseen. 

13.4.5 Management of FPR_UN0.4 

The following actions could be considered for the management functions in FMT: 

a) the list of authorised users that are capable of determining the occurence of operations, 

13.4.6 Audit of FPR_UN0.1, FPR_UN0.2 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: The invocation of the unobservability mechanism. 

13.4.7 Audit of FPR_UN0.3 

There are no auditable events foreseen. 

13.4.8 Audit of FPR_UN0.4 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: The observation of the use of a resourjce or service by a user or subject. 
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13.4.9 FPR_UN0.1 Unobservability 

Hierarchical to: No other components. 

Dependencies: No dependencies. 

13.4.9.1 FPR_UN0.1.1 

The TSF shall ensure that [assignment: list of users and/or subjects] are unable to observe the 
operation [assignment: list of operations] on [assignment: list of objects] by [assignment: list of 
protected users and/or subjects] . 

13.4.10 FPR_UN0.2 Allocation of information Impacting unobservability 

Hierarchical to: FPR_UN0.1 Unobservability 
Dependencies: No dependencies. 

13.4.10.1 FPR_UN0.2.1 

The TSF shall ensure that [assignment: list of users and/or subjects] are unable to observe the operation 
[assignment: list of operations] on [assignment: list of objects] by [assignment: list of protected users and/or 
subjects], 

13.4.10.2 FPR_UN0.2.2 

The TSF shall allocate the [assignment: unobservability related information] among different parts of 
the TOE such that the following conditions hold during the lifetime of the information: [assignment: 
list of conditions], 

13.4.11 FPR_UN0.3 Unobservability without soliciting information 

Hierarchical to: No other components. 

Dependencies: FPR_UN0.1 Unobservability 

13.4.11.1 FPR_UN0.3.1 

The TSF shall provide [assrgnment: list of services] to [assignment: list of subjects] without soliciting 
any reference to [assignment: privacy related information]. 

1 3.4.1 2 FPR_UN0.4 Authorised user observability 

Hierarchical to: No other components. 

Dependencies: No dependencies. 

13.4.12.1 FPR_UN0.4.1 

The TSF shall provide [assignment: set of authorised users] with the capability to observe the usage 
of [assignment: list of resources and/or services]. 

14 Class FPT: Protection of the TSF 

This class contains families of functional requirements that relate to the integrity and management of the 
mechanisms that provide the TSF (independent of TSP-specifics) and to the integrity of TSF data 
(independent of the specific contents of the TSP data). In some sense, families in this class may appear to 
duplicate components in the FDP: User data protection class; they may even be implemented using the same 
mechanisms. However, FDP: User data protection focuses on user data protection, while FPT: Protection of 
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the TSF focuses on TSF data protection. In fact, components from the FPT: Protection of the TSF class are 
necessary to provide requirements that the SFPs in the TOE cannot be tampered with or bypassed. 

From the point of view of this class, there are three significant portions for the TSF: 

a) The TSF's abstract machine, which is the virtual or physical machine upon which the specific TSF 
implementation under evaluation executes. 

b) The TSF's implementation, which executes on the abstract machine and implements the mechanisms 
that enforce the TSP. 

c) The TSF's data, which are the administrative databases that guide the enforcement of the TSP. 
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FPT AMT: Underlying abstract niachitie test 



FPT FLS: Fail secure 



FPTJTA: Availability of exported TSF data 



FPTJTC: Confidentiafity of exported TSF data 



FPT ITI: Integrity of exported TSF data 



FPT ITT: Iiitental TOE TSF data transfer 



FPT_PHP: TSF physical protection 



FPTRCV: Trusted recovery 



FPr_RPL; Replay detection 



FPT RVM: Reference mediation 



FPT SEP: Domain separation 



FPT_SSP: State syndirony protocol 



FPTSTM: Time stamps 



FPT_TDC: Inter-TSF TSF data consistency 



- 1 



FPT_TRC: Intenial TOE TSF data replication consistency I 



FPT TST: TSF self test 



Figure 56 - FPT: Protection of the TSF class decomposition 
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14.1 Underlying abstract machine test {FPT_AMT) 

14.1.1 Family Behaviour 

This family defines requirements for the TSF to perform testing to demonstrate the security assumptions made 
about the underlying abstract machine upon which the TSF relies. This "abstract" machine could be a 
hardware/firmware platform, or it could be some known and assessed hardware/software combination acting 
as a virtual machine. 

14.1.2 Component levelling 



FPTAMT: Underlying abstract machine test 



Figure 57 - FPT_AMT component levelling 

FPT_AMT.1 Abstract machine testing, provides for testing of the underlying abstract machine. 

14.1.3 Management of FPT_AMT.1 

The following actions could be considered for the management functions in FMT: 

a) management of the conditions under which abstract machine test occurs, such as during initial start-up, 
regular interval, or under specified conditions; 

b) management of the time interval if appropriate. 

14.1.4 Audit of FPT_AMT.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 

a) Basic: Execution of the tests of the underlying machine and the results of the tests. 

14.1.5 FPT_AMT.1 Abstract machine testing 
Hierarchical to: No other components. 
Dependencies: No dependencies. 
14.1.5.1 FPT_AMT.1.1 

The TSF shall run a suite of tests [selection: during initial start-up, periodically during normal 
operation, at the request of an authorised user,[assignment: other conditions^ to demonstrate the 
correct operation of the security assumptions provided by the abstract machine that underiies the 

14.2 Fall secure {FPT_FLS) 
14.2.1 Family Behaviour 

The requirements of this family ensure that the TOE will not violate its JSP in the event of identified categories 
of failures in the TSF. 
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14.2.2 Component levelling 



FPT FLS: Fail secure 



Figure 58 - FPT_FLS component levelling 

This family consists of only one component, FPT_FLS.1 Failure with preservation of secure state which 
requires that the TSF preserve a secure state in the face of the identified failures. 

14.2.3 Management of FPT_FLS.1 

There are no management activities foreseen. 

14.2.4 Audit of FPT_FLS.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 

n I /o I . 

a) Basic: Failure of the TSF. 

14.2.5 FPT_FLS.1 Failure with preservation of secure state 

Hierarchical to: No other components. 

Dependencies: ADV_SPM.1 Informal TOE security policy model 

14.2.5.1 FPT_FLS.1.1 

The TSF shall preserve a secure state when the following types of failures occur: [assignment: list of 
types of failures in the TSF\. 

14.3 Availability of exported TSF data (FPTJTA) 

14.3.1 Family Behaviour 

This family defines the rules for the prevention of loss of availability of TSF data moving between the TSF and 
a remote trusted IT product. This data could, for example, be TSF critical data such as passwords keys audit - 
data, or TSF executable code. 

14.3.2 Component levelling 



FPTJTA: Availability of exported TSF data 



Figure 59 - FPTJTA component levelling 

This family consists of only one component, FPT_ITA.1 Inter-TSF availability within a defined availability 
metric. This component requires that the TSF ensure, to an identified degree of probability, the availability of 
TSF data provided to a remote trusted IT product. 

14.3.3 iVIanagement of FPTJTA.1 

The following actions could be considered for the management functions in FMT: 

a) management of the list of types of TSF data that must be available to a remote trusted IT product. 
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14.3.4 Audit of FPT ITA.1 



The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: the absence of TSF data when required by a TOE. 

14.3.5 FPTJTA.1 Inter-TSF availability within a defined availability metric 

Hierarchical to: No other components. 

Dependencies: No dependencies. 

14.3.5.1 FPTJTA.1. 1 

The TSF shall ensure the availability of [assignment: list of types of TSF data] provided to a remote 
trusted IT product within [assignment: a defined availability metric] given the following conditions 
[assignment: conditions to ensure availability]. 

14.4 Confidentiality of exported TSF data (FPTJTC) 

14.4.1 Family Behaviour 

This family defines the rules for the protection from unauthorised disclosure of TSF data during transmission 
between the TSF and a remote trusted IT product. This data could, for example, be TSF critical data such as 
passwords, keys, audit data, or TSF executable code. 

14.4.2 Component levelling 



FPTJTC: Confidentiality of exported TSF data 



Figure 60 - FPTJTC component levelling 

This family consists of only one component. FPTJTC. 1 Inter-TSF confidentiality during transmission, which 
requires that the TSF ensure that data transmitted between the TSF and a remote trusted IT product is 
protected from disclospre while in transit. 

14.4.3 Management of FPTJTC.1 

There are no management activities foreseen. 

14.4.4 Audit of FPTJTC.1 

There are no auditable events foreseen. 

14.4.5 FPTJTC.1 Inter-TSF confidentiality during transmission 
Hierarchical to: No other components. 

Dependencies: No dependencies. 
14.4.5.1 FPTJTC.1. 1 

The TSF shall protect all TSF data transmitted from the TSF to a remote trusted IT product from 
unauthorised disclosure during transmission. 
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14.5 Integrity of exported TSF data (FPTJTI) 
14.5.1 Family Beliaviour 



This family defines the rules for the protection, from unauthorised modification, of TSF data during 
transmission between the TSF and a remote trusted IT product. This data could, for example, be TSF critical 
data such as passwords, keys, audit data, or TSF executable code. 

14.5.2 Component levelling 



FPTJTI: Integrity of exported TSF data 



Figure 61 - FPTJTI component levelling 

FPTJTI. 1 Inter-TSF detection of modification, provides the ability to detect modification of TSF data during 
transmission between the TSF and a remote trusted IT product, under the assumption that the remote trusted 
IT product is cognisant of the mechanism used. 

FPT_ITI.2 Inter-TSF detection and correction of modification, provides the ability for the remote trusted IT 
product not only to detect modification, but to correct modified TSF data under the assumption that the remote 
trusted IT product is cognisant of the mechanism used. 

14.5.3 Management Of FPTJTI.1 

There are no management activities foreseen. 

14.5.4 Management of FPTJTI.2 

The following actions could be considered for the management functions in FMT; 

a) management of the types of TSF data that the TSF should try to correct if modified in transit; 

b) management of the types of action that the TSF could take if TSF data is modified in transit. 

14.5.5 Audit Of FPTJTI.1 

The following actions should be auditable if FAU_GEN Security audit data generation is Included in the 
PP/ST: 

a) Minimal: the detection of modification of transmitted TSF data. 

b) Basic: the action taken upon detection of modification of transmitted TSF data. 

14.5.6 Audit of FPTJTI.2 

The following actions should be auditable if FAU 6en Security audit data generation is included in the 
PP/ST: 

a) Minimal: the detection of modification of transmitted TSF data; 

b) Basic: the action taken upon detection of modification of transmitted TSF data. 

c) Baste: the use of the correction mechanism. 

14.5.7 FPTJTI.1 Inter-TSF detection of modification 

Hierarchical to: No other components. 
Dependencies: No dependencies. 

86 



IS 14990 (Part 2) : 2006 
ISO/IEC 15408-2 : 2005 



14.5.7.1 FPT ITI.1.1 



The TSF shall provide the capability to detect modification of all TSF data during transmission 
between the TSF and a remote trusted IT product within the following metric: [assignment: a defined 
modification metric], 

14.5.7.2 FPT_m.1.2 

The TSF shall provide the capability to verify the integrity of all TSF data transmitted between the TSF 
and a remote trusted IT product and perform [assignment: acUon to be tai(en] if modifications are 
detected. 

14.5.8 FPTJTI.2 Inter-TSF detection and correction of modification 

Hierarchical to: FPT_ITI.1 Inter-TSF detection of modification 
Dependencies: No dependencies. 

14.5.8.1 FPTJTi.2.1 

The TSF shall provide the capability to detect modification of all TSF data during transmission between the 
TSF and a remote trusted IT product within the following metric: [assignment: a defined modification metric]. 

14.5.8.2 FPTJTI.2.2 

The TSF shall provide the capability to verify the integrity of all TSF data transmitted between the TSF and a 
remote trusted IT product and perform [assignment: action to be taken] if modifications are detected. 

14.5.8.3 FPT_ITI.2.3 

The TSF shall provide the capability to correct [assignment: type of modification] of all TSF data 
transmitted between the TSF and a remote trusted IT product. 

14.6 Internal TOE TSF data transfer (FPTJTT) 

14.6.1 Family Behaviour 

This family provides requirements that address protection of TSF data when it is transferred between separate 
parts of a TOE across an internal channel. 

14.6.2 Component levelling 



FPT ITT: Internal TOE TSF data transfer 



Figure 62 - FPTJTT component levelling 

FPT_ITT.1 Basic internal TSF data transfer protection, requires that TSF data be protected when transmitted 
between separate parts of the TOE. 

FPT_ITT.2 TSF data transfer separation, requires that the TSF separate user data from TSF data during 
transmission. 
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FPT_ITT.3 TSF data integrity monitoring, requires that the TSF data transmitted between separate parts of 
the TOE is monitored for identified integrity errors. 

14.6.3 Management of FPTJTT.1 

The following actions could be considered for the management functions in FMT: 

a) management of the types of modification against which the TSF should protect; 

b) management of the mechanism used to provide the protection of the data in transit between different 
parts of the TSF. 

14.6.4 Management of FPTJTT.2 

The following actions could be considered for the management functions in FMT: 

a) management of the types of modification against which the TSF should protect; 

b) management of the mechanism used to provide the protection of the data in transit between different 
parts of the TSF; 

c) management of the separation mechanism. 

14.6.5 Management of FPT_ITT.3 

The following actions could be considered for the management functions In FMT: 

a) management of the types of modification against which the TSF should protect; 

b) management of the mechanism used to provide the protection of the data in transit between different 
parts of the TSF; 

c) management of the types of modification of TSF data the TSF should try to detect; 

d) management of the action>s that will be taken. 

14.6.6 Audit of FPTJTT.1, FPTJTT.2 
There are no auditable events foreseen. 

14.6.7 Audit of FPTJTT.3 

The following actions should be auditable If FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: the detection of modification of TSF data; 

b) Basic: the action taken following detection of an integrity error. 

14.6.8 FPTJTT.1 Basic internal TSF data transfer protection 
Hierarchical to: No other components. 

Dependencies: No dependencies. 
14.6.8.1 FPTJTT.1.1 

The TSF shall protect TSF data from [selection: disclosure, modmcation] when it is transmitted 
between separate parts of the TOE. 
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14.6.9 FPTJTT.2 TSF data transfer separation 

Hierarchical to: FPTJTT.1 Basic internal TSF data transfer protection 
Dependencies: No dependencies. 

14.6.9.1 FPTJTT.2.1 

The TSF shall protect TSF data from [selection: disclosure, modification] when it is transmitted between 
separate parts of the TOE. 

14.6.9.2 FPTJTT.2.2 

The TSF shall separate user data from TSF data when such data is transmitted between separate parts 
of the TOE. 

14.6.10 FPTJTT.3 TSF data integrity monitoring 

Hierarchical to: No other components. 

Dependencies: FPT_ITT.1 Basic internal TSF data transfer protection 

14.6.10.1 FPTJTT.3.1 

The TSF shall be able to detect [selection: modi^cation of data, substitution of data, re-ordering of 
data, deletion of data„[assignment: other integrity errors]\ for TSF data transmitted between separate 
parts of the TOE. 

14.6.10.2 FPTJTT.3.2 

Upon detection of a data integrity error, the TSF shall take the following actions: [assignment: specify 
ttie action to be taken]. 

UJ TSF physical protection {FPT_PHP) 

14.7.1 Family Behaviour * 

TSF physical protection components refer to restrictions on unauthorised physical access to the TSF, and to 
the deterrence of, and resistance to, unauthorised physical modification, or substitution of the TSF. 

The requirements of components in this family ensure that the TSF is protected from physical tampering and 
interference. Satisfying the requirements of these components results in the TSF being packaged and used in 
such a manner that physical tampering is detectable, or resistance to physical tampering is enforced. Without 
these components, the protection functions of a TSF lose their effectiveness in environments where physical 
damage cannot be prevented. This family also provides requirements regarding how the TSF shall respond to 
physical tampering attempts. 

14.7.2 Component levelling 



FPT_PHP: TSF physical protection 



Figure 63 - FPT_PHP component levelling 

FPT_PHP.1 Passive detection of physical attack, provides for features that indicate when a TSF device or 
TSF element is subject to tampering. However, notification of tampering is not automatic; an authorised user 
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must invoke a security administrative function or perform manual inspection to determining If tampering has 
occurred. 

FPT_PHP.2 Notification of physical attack, provides for automatic notification of tampering for an identified 
subset of physical penetrations. 

FPT_PHP.3 Resistance to physical attack, provides for features that prevent or resist physical tampering with 
TSF devices and TSF elements. 

14.7.3 Management of FPT_PHP.1 

The following actions could be considered for the management functions in FMT: 

a) management of the user or role that determines whether physical tampering has occurred. 

14.7.4 Management of FPT_PHP.2 

The following actions could be considered for the management functions in FMT: 

a) management of the user or role that gets informed about intrusions; 

b) management of the list of devices that should inform the indicated user or role about the intrusion. 

14.7.5 Management of FPT_PHP.3 

The following actions could be considered for the management functions In FMT: 
a) management of the automatic responses to physical tampering. 

14.7.6 Audit of FPT_PHP.1 

The following actions should be audltable if FAU_GEN Security audit data generation Is included In the 
PP/ST: 

a) Minimal: if detection by IT means, detection of intrusion. 

14.7.7 Audit of FPT_PHP.2 

The following actions should be audltable If FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: detection of Intrusion. 

14.7.8 Audit of FPT_PHP.3 

There are no auditable events foreseen. 

14.7.9 FPT_PHP.1 Passive detection of physical attack 
Hierarchical to: No other components. 
Dependencies: No dependencies. 

14.7.9.1 FPT_PHP.1.1 

The TSF shall provide unambiguous detection of physical tampering that might compromise the TSF. 
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14.7.9.2 fPT PHP.1.2 



The TSF shall provide the capability to determine whether physical tampering with the TSF's devices 
or TSF's elements has occurred. 

14.7.1 FPT_PHP.2 Notification of physical attack 

Hierarchical to: FPT_PHP.1 Passive detection of physical attack 
Dependencies: FMT_M0F.1 Management of security functions behaviour 

14.7.10.1 FPT_PHP.2.1 

The TSF shall provide unambiguous detection of physical tampering that might compromise the TSF. 

14.7.10.2 FPT_PHP.2.2 

The TSF shall provide the capability to determine whether physical tampering with the TSF's devices or TSF's 
elements has occurred. 

14.7.10.3 FPT_PHP.2.3 

For [assignment: list of TSF devices/elements for which active detection is required\, the TSF shall 
monitor the devices and elements and notify [assignment: a designated user or role] when physical 
tampering with the TSF's devices or TSF's elements has occurred. 

14.7.1 1 FPT_PHP.3 Resistance to physical attack 

Hierarchical to: No other components. 

Dependencies: No dependencies. 

14.7.11.1 FPT_PHP.3.1 

The TSF shall resist [assignment: physical tampering scenarios] to the [assignment: list of TSF 
devices/elements] by responding automatically such that the TSP is not violated. 

14.8 Trusted recovery (FPT_RCV) 

14.8.1 Family Behaviour 

The requirements of this family ensure that the TSF can determine that the TOE is started up without 
protection compromise and can recover without protection compromise after discontinuity of operations. This 
family is important because the start-up state of the TSF determines the protection of subsequent states. 

14.8.2 Component levelling 



FPT_RC'V: Trusted recovery 



Figure 64 - FPT_RCV component levelling 

FPT_RCV.1 Manual recovery, allows a TOE to only provide mechanisms that involve human intervention to 
return to a secure state. 

FPT_RCV.2 Automated recovery, provides, for at least one type of service discontinuity, recovery to a secure 
state without human intervention; recovery for other discontinuities may require human intervention. 
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FPT_RCV.3 Automated recovery without undue loss, also provides for automated recovery, but strengthens 
the requirements by disallowing undue loss of protected objects. y = => 

FPT RCV.4 Furiction recovery, provides for recovery at the level of particular SFs, ensuring either successful 
completion or rollback of TSF data to a secure state. successiui 

14.8.3 Management of FPT_RCV.1 

The following actions could be considered for the management functions In FMT: 

a) management of who can access the restore capability within the maintenance mode. 

14.8.4 Management of FPT_RCV.2, FPT_RCV.3 

The following actions could be considered for the management functions In FMT: 

a) management of who can access the restore capability within the maintenance mode; 

b) management of the list of failures/service discontinuities that will be handled through the automatic 
procedures. 

14.8.5 Management of FPT_RCV.4 

There are no management activities foreseen. 

14.8.6 Audit of FPT_RCV.1, FPT_RCV.2, FPT_RCV.3 

Thyollowing actions should be auditable if FAU_GEN Security audit data generation is included in the 

a) Minimal: the fact that a failure or service discontinuity occurred; 

b) Minimal: resumption of the regular operation; 

c) Basic: type of failure or service discontinuity. 

14.8.7 Audit Of FPT_RCV.4 

The^following actions should be auditable if FAU_GEN Security audit data generation is included in the 

a) Minimal: if possible, the impossibility to return to a secure state after failure of a security function; 

b) Basic: if possible, the detection of a failure of a security function. 

14.8.8 FPT_RCV.1 Manual recovery 
Hierarchical to: No other components. 
Dependencies: AGD_ADM.1 Administrator guidance 

ADV_SPM.1 Informal TOE security policy model 
14.8.8.1 FPT_RCV.1.1 

After [assignment: list of failures/service discontinuities] the TSF sliali enter a maintenance mode 
where the ability to return to a secure state is provided. 



92 



IS 14990 (Part 2): 2006 
ISO/IEC 15408-2: 2005 

14.8.9 FPT_RCV.2 Automated recovery 

Hierarchical to: FPT_RCV.1 Manual recovery 
Dependencies: AGD_ADM.1 Administrator guidance 

ADV_SPM.1 Informal TOE security policy model 

14.8.9.1 FPT_RCV.2.1 

When automated recovery from [assignment: list of failures/service discontinuities] is not possible, the TSF 
shall enter a maintenance mode where the ability to return to a secure state is provided. 

14.8.9.2 FPT_RCV.2.2 

For [assignment: list of failures/service discontinuities], the TSF shall ensure the return of the TOE to 
a secure state using automated procedures. 

14.5.10 FPT_RCV.3 Automated recovery without undue loss 

Hierarchical to: FPT_RCV.2 Automated recovery 
Dependencies: AGD_ADM.1 Administrator guidance 

ADV_SPM.1 Informal TOE security policy model 

14.8.10.1 FPT_RCV.3.1 

When automated recovery from [assignment: list of failures/service discontinuities] is not possible, the TSF 
shall enter a maintenance mode where the ability to return to a secure state is provided. 

14.8.10.2 FPT_RCV.3.2 

For [assignment: list of failures/service discontinuities], the TSF shall ensure the return of the TOE to a secure 
state using automated procedures. 

14.8.10.3 FPT_RCV.3.3 

The functions provided by the TSF to recover from failure or service discontinuity shall ensure that 
the secure initial state is restored without exceeding [assignment: quantification] for loss of TSF data 
or objects within the TSC. 

14.8.10.4 FPT_RCV.3.4 

The TSF shall provide the capability to determine the objects that were or were not capable of being 
recovered. 

14.8.11 FPT_RCV.4 Function recovery 

Hierarchical to: No other components. 

Dependencies: ADV_SPM.1 Informal TOE security policy model 

14.8.11.1 FPT_RCV.4.1 

The TSF shall ensure that [assignment: list ofSFs and failure scenarios] have the property that the SF 
either completes successfully, or for the indicated failure scenarios, recovers to a consistent and 
secure state. 
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14.9 Replay detection (FPT_RPL) 
14.9.1 Family Behaviour 



This family addresses detection of replay for various types of entitles (e.g. messages, service requests, 
service responses) and subsequent actions to correct. In the case where replay may be detected, this 
effectively prevents it. 

14.9.2 Component levelling 



FPT_RPL: Replay detection 



Figure 65 - FPT_RPL component levelling 

The family consists of only one component, FPT_RPL.1 Replay detection, which requires that the TSF shall 
be able to detect the replay of identified entities. 

14.9.3 Management of FPT_RPL.1 

The following actions could be considered for the management functions in FMT: 

a) management of the list of identified entities for which replay shall be detected; 

b) management of the list of actions that need to be taken in case of replay. 

14.9.4 Audit of FPT_RPL.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Basic: Detected replay attacks. 

b) Detailed: Action to be taken based on the specific actions. 

14.9.5 FPT_RPL.1 Replay detection 
Hierarchical to: No other components. 
Dependencies; No dependencies. 

14.9.5.1 FPT_RPL.1.1 

The TSF shall detect replay for the following entities: [assignment: list of identified entities]. 

14.9.5.2 FPT_RPL.1.2 

The TSF shall perform [assignment: list of specific actions] when replay is detected. 

14,10 Reference mediation (FPT_RVM) 

14.10.1 Family Behaviour 

The requirements of this family address the "always invoked" aspect of a traditional reference monitor. The 
goal of this family is to ensure, with respect to a given SFP, that alt actions requiring policy enforcement are 
validated by the TSF against the SFP. If the portion of the TSF that enforces the SFP also meets the 
requirements of appropriate components from Domain separation (FPT_SEP) and TSF internals (ADVJNT), 
then that portion of the TSF provides a "reference monitor" for that SFP. 
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A TSF that implements a SFP provides effective protection against unauthorised operation if artd only if all 
enforceable actions (e.g. accesses to objects) requested by untrusted subjects with respect to any or all of 
that SFP are validated by the TSF before succeeding. If an action that could be enforceable by the TSF, is 
incorrectly enforced or incorrectly bypassed, the overall enforcement of the SFP could be compromised. 
Subjects could then bypass the SFP in a variety of unauthorised ways (e.g. circumvent access checks for 
some subjects or objects, bypass checks for objects whose protection was assumed by applications, retain 
access rights beyond their intended lifetime, bypass auditing of audited actions, or bypass authentication). 
Note that some subjects, the so called "trusted subjects" with respect to a specific SFP, might be trusted to 
enforce the SFP by themselves, and bypass the mediation of the SFP. 

14.10.2 Component levelling 



FPT RVM: Reference mediation 



Figure 66 - FPT_RVM component levelling 

This family consists of only one component, FPT_RVM.1 Non-bypassability of the TSP, which requires non- 
bypassability for all SFPs in the TSP. 

14.10.3 Management of FPT_RVM.1 

There are no management activities foreseen. 

14.10.4 Audit Of FPT_RVM.1 

There are no auditable events foreseen. 

14.10.5 FPT_RVM.1 Non-bypassability of tlie TSP 
Hierarchical to: No other components. 
Dependencies: No dependencies. 

14.10.5.1 FPT_RVM.1.1 

The TSF shall ensure that TSP enforcement functions are invoked and succeed before each function 
within the TSC is allowed to proceed. 

14.11 Domain separation (FPT_SEP) 
14.1 1 .1 Family Behaviour 

The components of this family ensure that at least one security domain is available for the TSF's own 
execution and that the TSF Is protected from external interference and tampering (e.g. by modification of TSF 
code or data structures) by untrusted subjects. Satisfying the requirements of this family makes the TSF self- 
protecting, meaning that an untrusted subject cannot modify or damage the TSF. 

This family requires the following: 

a) The resources of the TSF's security domain ("protected domain") and those of subjects and 
unconstrained entities external to the domain are separated such that the entities external to the 
protected domain cannot observe or modify TSF data or TSF code internal to the protected domain. 

b) The transfers between domains are controlled such that arbitrary entry to, or return from, the protected 
domain is not possible. 
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c) The user or application parameters passed to the protected domain by addresses are validated with 
respect to the protected domain's address space, and those passed by value are validated with respect to 
the values expected by the protected domain. 

d) The security domains of subjects are distinct except for controlled sharing via the TSF. 
14.11.2 Component levelling 



FPT_SEP: Domain separation 



Figure 67 - FPT_SEP component levelling 

FPT_SEP.1 TSF domain separation, provides a distinct protected domain for the TSF and provides separation 
between subjects within the TSC. 

FPT_SEP.2 SFP domain separation, requires that the TSF be further subdivided, with distinct domain(s) for 
an identified set of SFPs that act as reference monitors for their policies, and a domain for the remainder of 
the TSF, as well as domains for the non-TSF portions of the TOE. 

FPT_SEP.3 Complete reference monitor, requires that there be distinct domain(s) for TSP enforcement, a 
domain for the remainder of the TSF, as well as domains for the non-TSF portions of the TOE. 

14.11.3 Management of FPT_SEP.1, FPT_SEP.2, FPT_SEP.3 

There are no management activities foreseen. 

14.11.4 Auditor FPT_SEP.1, FPT_SEP.2, FPT_SEP.3 
There are no auditable events foreseen. 

14.11.5 FPT_SEP.1 TSF domain separation 
Hierarchical to: No other components. 
Dependencies: No dependencies. 

14.11.5.1 FPT_SEP.1.1 

The TSF shall maintain a security domain for its own execution that protects it from interference and 
tampering by untrusted subjects. 

14.11.5.2 FPT_SEP.1.2 

The TSF shall enforce separation between the security domains of subjects in the TSC. 

14.1 1 .6 FPT_SEP.2 SFP domain separation 

Hierarchical to: FPT_SEP.1 TSF domain separation 

Dependencies: No dependencies, 

14.11.6.1 FPT_SEP.2.1 

The unisolated portion of the TSF shall maintain a security domain for its own execution that protects it from 
interference and tampering by untrusted subjects. 
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14.11.6.2 FPT_SEP.2.2 

The TSF shall enforce separation between the security domains of subjects in the TSC. 

14.11.6.3 FPT_SEP.2.3 

The TSF shall maintain the part of the TSF related to [assignment: list of access control and/or 
information flow control SFPs] in a security domain for their own execution that protects them from 
interference and tampering by the remainder of the TSF and by subjects untrusted with respect to 
those SFPs. 

14.11.7 FPT_SEP.3 Complete reference monitor 

Hierarchical to; FPT_SEP.2 SFP domain separation 
Dependencies: No dependencies. 

14.11.7.1 FPT_SEP.3.1 

The unisolated portion of the TSF shall maintain a security domain for its own execution that protects it from 
interference and tampering by untrusted subjects. 

14.11.7.2 FPT_SEP.3.2 

The TSF shall enforce separation between the security domairrs of subjects in the TSC. 

14.11.7.3 FPT_SEP.3.3 

The TSF shall maintain the part of the TSF that enforces the access control and/or information flow control 
SFPs in a security domain for its own execution that protects them from interference and tampering by the 
remainder of the TSF and by subjects untrusted with respect to the TSP, 

14.12 State synchrony protocol {FPT_SSP) 

14.12.1 Family Behaviour 

Distributed systems may give rise to greater complexity than monolithic systems through the potential for 
differences in state between parts of the system, and through delays in communication. In most cases 
synchronisation of state between distributed functions involves an exchange protocol, not a simple action. 
When malice exists in the distributed environment of these protocols, more complex defensive protocols are 
required. 

State synchrony protocol (FPT_SSP) establishes the requirement for certain critical security functions of the 
TSF to use this trusted protocol. State synchrony protocol (FPT_SSP) ensures that two distributed parts of the 
TOE (e.g. hosts) have synchronised their states after a security-relevant action. 

14.12.2 Component levelling 



FPTSSP: State synchrony protocol 



Figure 68 - FPT_SSP component levelling 

FPTSSP.I Simple trusted acknowledgement, requires only a simple acknowledgment by the data recipient. 
FPT_SSP.2 Mutual trusted acknowledgement, requires mutual acknowledgment of the data exchange. 
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14.12.3 Management of FPT_SS P. 1,FPT_SSP.2 

There are no management activities foreseen. 

14.12.4 Audit of FPT_SSP.1, FPT_SSP.2 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 

a) Minimal; failure to receive an acknowledgement when expected. 

14.12.5 FPT_SSP.1 Simple trusted acltnowledgement 
Hierarchicalio: No other components. 

Dependencies: FPTJTT.I Basic internal TSF data transfer protection 
14.12.5.1 FPT_SSP.1.1 

The TSF shall acknowledge, when requested by another part of the TSF, the receipt of an unmodified 
TSF data transmission. 

14.12.6 FPT_SSP.2 Mutual trusted acknowledgement 

Hierarchical to: FPT_SSP. 1 Simple trusted acknowledgement 
Dependencies: FPTJTT.I Basic internal TSF data transfer protection 

14.12.6.1 FPT_SSP.2.1 

The TSF shall acknowledge, when requested by another part of the TSF, the receipt of an unmodified TSF 
data transmission. 

14.12.6.2 FPT_SSP.2.2 

The TSF shall ensure that the relevant parts of the TSF know the correct status of transmitted data 
among its different parts, using acknowledgements. 

14.13 Time stamps (FPT_STM) 

14.13.1 Family Behaviour 

This family addresses requirements for a reliable time stamp function within a TOE. 

14.13.2 Component levelling 



FPTSTM: Time stamps 



Figure 69 - FPT_STM component levelling 

This family consists of only one component, FPT_STM.1 Reliable time stamps, which requires that the TSF 
provide reliable time stamps for TSF functions. 

14.13.3 Management of FPT_STM.1 

The following actions could be considered for the management functions in FMT: 
a) management of the time. 
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1 4.1 3.4 Audit of FPT_STM.1 



The following actions should be audltable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: changes to the time; 

b) Detailed: providing a timestamp. 
14.13.5 FPT„STM.1 Reliable time stamps 
Hierarchical to: No other components. 
Dependencies: No dependencies. 
14.13.5.1 FPT_STM.1.1 

The TSF shall be able to provide reliable time stamps for its own use. 
14.14 Inter-TSF TSF data consistency (FPT_TDC) 

14.14.1 Family Behaviour 

In a distributed or composite system environment, a TOE may need to exchange TSF data (e.g. the SFP- 
attributes associated with data, audit information, identification information) with another trusted IT product. 
This family defines the requirements for sharing and consistent interpretation of these attributes between the 
TSF of the TOE and a different trusted IT product. 

14.14.2 Component levelling 



FPT_TDC: Inter TSF TSF data consistency 



Figure 70 - FPT_TDC component levelling 

FPT_TDC.1 Inter-TSF basic TSF data consistency, requires that the TSF provide the capability to ensure 
consistency of attributes between TSFs. 

14.14.3 Management of FPT_TDC.1 

There are no management activities foreseen. 

14.14.4 Audit of FPT_TDC.1 

The following actions should be audltable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: Successful use of TSF data consistency mechanisms. 

b) Basic: Use of the TSF data consistency mechanisms. 

c) Basic: Identification of which TSF data have been interpreted. 

d) Basic: Detection of modified TSF data. 
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14.14.5 FPT_TDC.1 Inter-TSF basic TSF data consistency 

Hierarchical to: No other components. 
Dependencies: No dependencies. 

14.14.5.1 FPT_TDC.1.1 

The TSF shall provide the capability to consistently interpret [assignment: list of TSF data types] when 
shared between the TSF and another trusted IT product. 

14.14.5.2 FPT_TDC.1.2 

The TSF shall use [assignment: list of interpretation rules to be applied by the TSF] when interpreting 
the TSF data from another trusted IT product. 

14.15 Internal TOE TSF data replication consistency (FPT_TRC) 

14.15.1 Family Behaviour 

The requirements of this family are needed to ensure the consistency of TSF data when such data is 
replicated internal to the TOE. Such data may become inconsistent if the internal channel between parts of the 
TOE becomes inoperative. If the TOE is internally structured as a network and parts of the TOE network 
connections are broken, this may occur when parts become disabled. 

14.15.2 Component levelling 



FPT_TRC: Internal TOE TSF data replication consistency 



} 



Figure 71 - FPT_TRC component levelling 

This family consists of only one component, FPT_TRC.1 Internal TSF consistency, which requires that the 
TSF ensure the consistency of TSF data that is replicated in multiple locations. 

14.15.3 Management Of FPT_TRC.1 

There are no management activities foreseen. 

14.15.4 Audit of FPT_TRC.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: restoring consistency upon reconnection. 

b) Basic: Detected inconsistency between TSF data. 

14.15.5 FPT_TRC.1 Internal TSF consistency 
Hierarchical to: No other components. 

Dependencies: FPTJTT. 1 Basic internal TSF data transfer protection 

14.15.5 1 FPT_TRC.1.1 

The TSF shall ensure that TSF data is consistent when replicated between parts of the TOE. 
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14.15.5.2 FPT TRC.1.2 



When parts of the TOE containing replicated TSF data are disconnected, the TSF shall ensure the 
consistency of the replicated TSF data upon reconnection before processing any requests for 
[assignment: list ofSFs dependent on TSF data replication consistency\. 

14.16 TSF self test (FPT_TST) 

14.16.1 Family Behaviour 

The family defines the requirements for the self-testing of the TSF with respect to some expected correct 
operation. Examples are interfaces to enforcement functions, and sample arithmetical operations on critical 
parts of the TOE. These tests can be carried out at start-up. periodically, at the request of the authorised user, 
or when other conditions are met. The actions to be taken by the TOE as the result of self testing are defined 
in other families. 

The requirements of this family are also needed to detect the corruption of TSF executable code (i.e. TSF 
software) and TSF data by various failures that do not necessarily stop the TOE's operation (which would be 
handled by other families). These checks must be performed because these failures may not necessarily be 
prevented. Such failures can occur either because of unforeseen failure modes or associated oversights in the 
design of hardware, firmware, or software, or because of malicious corruption of the TSF due to inadequate 
logical and/or physical protection. 

14.16.2 Component levelling 



FPT TST: TSF self test 



Figure 72 - FPT_TST component levelling 

FPT_TST.1 TSF testing, provides the ability to test the TSF's correct operation. These tests may be 
performed at start-up. periodically, at the request of the authorised user, or when other conditions are met. It 
also provides the ability to verify the integrity of TSF data and executable code. 

14.16.3 Management of FPT_TST.1 

The following actions could be considered for the management functions in FMT: 

a) management of the conditions under which TSF self testing occurs, such as during initial start-up, regular 
interval, or under specified conditions; 

b) management of the time interval if appropriate. 

14.16.4 Audit of FPT_TST.1 

The following actions should be auditable if FAU GEN Security audit data generation is included in the 
PP/ST: 

a) Basic: Execution of the TSF self tests and the results of the tests. 

14.16.5 FPT_TST.1 TSF testing 
Hierarchical to: No other components. 
Dependencies: FPT_AMT.1 Abstract machine testing 
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14.16.5.1 FPT_TST.1.1 

The TSF shall run a suite of self tests [selection: during initial start-up, periodically during normal 
operation, at the request of the authorised user, at theconditions[assignment: conditions under which 
self test should occurJ\ to demonstrate the correct operation of the TSF. operation of [selection: 
[assignment: parts of TSF], the TSF]. 

14.16.5.2 FPT_TST.1.2 

The TSF shall provide authorised users with the capiability to verify the integrity of [selection: 
[assignment: parts of TSF], TSF data]. 

14.16.5.3 FPT_TST.1.3 

The TSF shall provide authorised users with the capability to verify the integrity of stored TSF 
executable code. 

15 Class FRU: Resource utilisation 

This class provides three families that support the availability of required resources such as processing 
capability and/or storage capacity. The family Fault Tolerance provides protection against unavailability of 
capabilities caused by failure of the TOE. The family Priority of Service ensures that the resources will be 
allocated to the more important or time-critical tasks and cannot be monopolised by lower priority tasks. The 
family Resource Allocation provides limits on the use of available resources, therefore preventing users from 
monopolising the resources. 



FRU Fl.T; Fault loleiniice 



FRU PRS: Piiorit\- ot'sei-\i\.'e 



FRU RS.A.. Resowrce allocalion 



Figure 73 - FRU: Resource utilisation class decomposition 
15.1 Fault tolerance (FRU_FLT) 

15.1.1 Family Behaviour 

The requirements of this family ensure that the TOE will maintain correct operation even in the event of 
failures. 

15.1.2 Component levelling 



FRU FLT: Fault (oleraiu-e 



Figure 74 - FRU_FLT component levelling 

FRU_FLT.1 Degraded fault tolerance, requires the TOE to continue correct operation of identified capabilities 
in the event of identified failures. 

FRU_FLT.2 Limited fault tolerance, requires the TOE to continue correct operation of all capabilities in the 
event of identified failures. 
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15.1.3 Management of FRU_FLT.1, FRU_FLT.2 

There are no management activities foreseen. 

15.1.4 Audit of FRU^FLT.I 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: Any failure detected by the TSF. 

b) Basic: All TOE capabilities being discontinued due to a failure. 

15.1.5 Audit of FRU„FLT.2 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: Any failure detected by the TSF. 

15.1.6 FRU_FLT.1 Degraded fault tolerance 
Hierarchical to: No other components. 

Dependencies: FPT_FLS.1 Failure with preservation of secure state 

15.1.6.1 FRU_FLT.1.1 

The TSF shalJ ensure the operation of [assignment: list of TOE capabilities] when the following 
failures occur: [assignment: list of type of failures]. 

15.1.7 FRU_FLT.2 Limited fault tolerance 

Hierarchical to: FRU_FLT.1 Degraded fault tolerance 

Dependencies: FPT_FLS.1 Failure with preservation of secure state 

15.1.7.1 FRU_FLT.2.1 

The TSF shall ensure the operation of all the TOE's capabilities when the following failures occur: 
[assignment: list of type of failures]. 

15.2 Priority of service (FRU_PRS) 

15.2.1 Family Behaviour 

The requirements of this family allow the TSF to control the use of resources within the TSC by users and 
subjects such that high priority activities within the TSC will always be accomplished without undue 
interference or delay caused by low priority activities. 

15.2.2 Component levelling 



FRU PRS: Priority of service 



Figure 75 - FRU_PRS component levelling 
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FRU_PRS.1 Limited priority of service, provides priorities for a subject's use of a sut>set of the resources 
within the TSC. 

FRU_PRS.2 Full priority of service, provides priorities for a subject's use of all of the resources within the TSC. 

15.2.3 Management Of FRU_PRS.1, FRU_PRS.2 

The following actions could be considered for the management functions in FMT: 
a) assignment of priorities to each subject In the TSF. 

15.2.4 Audit of FRU_PRS.1, FRU_PRS.2 

The following actions should be audltable If FAU_GEN Security audit data generation Is included in the 
PP/ST: 

a) Minimal: Rejection of operation based t)n the use of priority within an allocation. 

b) Basic: All attempted uses of the allocation function which Involves the priority of the service functions. 
15.2:5 FRU_PRS.1 Limited priority of service 

Hierarchical to: No other components. 
Dependencies: No dependencies. 

15.2.5.1 FRU_PRS.1.1 

The TSF shall assign a priority to each subject in the TSF. 

15.2.5.2 FRU_PRS.1.2 

The TSF shall ensure that each access to [assignment: controlled resources] shall be mediated on the 
basis of the subjects assigned priority. 

15.2.6 FRU_PRS.2 Full priority of service 

Hierarchical to: FRU_PRS.1 Limited priority of service 
Dependencies: No dependencies. 

15.2.6.1 FRU_PRS.2.1 

The TSF shall assign a priority to each subject in the TSF. 

15.2.6.2 FR0_PRS.2.2 

The TSF ^hall ensure that each access to all shareable resources shall be mediated on the basis of the 
subjects assigned priority. 

15.3 Resource allocation (FRU_RSA) 

15.3.1 Family Behaviour 

The requirements of this family allow the TSF to control the use of resources by users and subjects such that 
denial of service will not occur because of unauthorised monopolisation of resources. 
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15.3.2 Component levelling 



FRURSA: Resource allocation 



Figure 76 - FRU_RSA component levelling 

FRU_RSA.1 Maximum quotas, provides requirements for quota mechanisms ttiat ensure that users and 
subjects will not monopolise a controlled resource. 

FRU_RSA.2 Minimum and maximum quotas, provides requirements for quota mechanisms that ensure that 
users and subjects will always have at least a minimum of a specified resource and that they will not be able 
to monopolise a controlled resource. 

15.3.3 Management of FRU_RSA.1 

The following actions could be considered for the management functions in FMT: 

a) specifying maximum limits for a resource for groups and/or individual users and/or subjects by an 
administrator. 

15.3.4 Management of FRU_RSA.2 

The following actions could be considered for the management functions in FMT: 

a) specifying minimum and maximum limits for a resource for groups and/or individual users and/or subjects 
by an administrator. 

t5.3.5 Audit of FRU_RSA.1, FRU_RSA.2 

The following actions should be audltable If FAU_GEN Security audit data generation Is included in the 

a) Minimal: Rejection of allocation operation due to resource limits. 

b) Basic: All attempted uses of the resource allocation functions for resources that are under control of the 

15.3.6 FRU_RSA.1 Maximum quotas 

Hierarchical to: No other components. 
Dependencies: No dependencies. 
15.3.6.1 FRU_RSA.1.1 

The TSF shall enforce maximum quotas of the following resources: [assignment: controlled 
resources] that [selection: individual user, defined group of users, subjects] can use [selection- 
simultaneously, over a speci^ed period of time]. 

15.3.7 FRU_RSA.2 Minimum and maximum quotas 

Hierarchical to: FRU_RSA.1 Maximum quotas 
Dependencies: No dependencies. 
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15.3.7.1 FRU_RSA.2.1 

The TSF shall enforce maximum quotas of the following resources [assignment: controlled resources] that 
[selection: individual user, defined group of users] can use [selection: simultaneously, over a specified period 
of time]. 

15.3.7.2 FRU_RSA.2.2 

Ttre TSF shall ensure the provision of minimum quantity of each [assignment: controlled resource] 
that is available for [selection: an individual user, defined group of users, subjects] to use [selection: 
simultaneously, over a specified period of time]. 

16 Class FTA: TOE access 

This family specifies functional requirements for controlling the establishment of a user's session. 



FTALSA: Limitation on scope of selectable attributes 



FTAMCS: Limitation on multiple coiicuirent sessions 



FTASSL: Session locking 



FTATAB: TOE access banners 



FTA TAII: TOE access liistory 



FTA TSE: TOP. session establishment 



Figure 77 - FTA: TOE access class decomposition 
16.1 Limitation on scope of selectable attributes (FTA_LSA) 

16.1.1 Family Behaviour 

This family defines requirements to limit the scope of session security attributes that a user may select for a 
session. 

16.1.2 Component levelling 



FTA_LSA: Limitation on scope of selectable attributes 



Figure 78 - FTA_LSA component levelling 

FTA_LSA.1 Limitation on scope of selectable attributes, provides the requirement for a TOE to limit the scope 
of the session security attributes during session establishment. 
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16.1 .3 Management of FTA_LSA.1 

The following actions could be considered for the management functions In FMT: 
a) management of the scope of the session security attributes by an administrator. 

16.1.4 Audit of FTA_LSA.1 

The following actions should be auditable If FAU_GEN Security audit data generation Is included in the 
PP/ST: 

a) Minimal: All failed attempts at selecting a session security attributes; 

b) Basic: All attempts at selecting a session security attributes; 

c) Detailed: Capture of the values of each session security attributes. 

16.1.5 FTA_LSA.1 Limitation on scope of selectable attributes 
Hierarchical to: No other components. 

Dependencies: No dependencies: 
16.1.5.1 FTA_LSA.1.1 

The TSF shall restrict the scope of the session security attributes [assignment: session security 
attributes], based on [assignment: attributes]. 

16.2 Limitation on multiple concurrent sessions (FTA_MCS) 

16.2.1 Family Behaviour 

This family defines requirements to place limits on the number of concurrent sessions that belong to the same 
user. 

16.2.2 Component levelling 



FTAMCS: Limitation on multiple concurrent sessions 



Figure 79 - FTA_MCS component levelling 

FTA_MCS.1 Basic limitation on multiple concurrent sessions, provides limitations that apply to all users of the 
TSF. 

FTA_MCS.2 Per user attribute limitation on multiple concurrent sessions extends FTA_MCS.1 Basic limitation 
on multiple concurrent sessions by requiring the ability to specify limitations on the number of concurrent 
sessions based on the related security attributes. 

16.2.3 Management of FTA_MCS.1 

The following actions could be considered for the management functions in FMT: 

a) management of the maximum allowed number of concun-ent user sessions by an administrator. 
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16.2.4 Management of FTA_MCS.2 

The following actions could be considered for the management functions in FMT: 

a) management of the rules that govern the maximum allowed number of concurrent user sessions by an 
administrator. 

16.2.5 Audit Of FTA_MCS.1, FTA_MCS.2 

The following actions should be auditable If FAU_GEN Security audit data generation Is Included in the 

PP/ST: 

a) Minimal: Rejection of a new session based on the limitation of multiple concurrent sessions. 

b) Detailed: Capture of the number of currently concurrent user sessions and the user security attFlbute(s). 

16.2.6 FTA_MCS.1 Basic limitation on multiple concurrent sessions 
Hierarchical to: No other components. 

Dependencies: FIA_LHD.1 Timing of identification 

16.2.6.1 FTA_MCS.1.1 

The TSF shall restrict the maximum number of concurrent sessions that belong to the same user. 

16.2.6.2 FTA_MCS.1.2 

The TSF shall enforce, by default, a limit of [assignment: default numbei] sessions per user. 

16.2.7 FTA_MCS.2 Per user attribute limitation on multiple concurrent sessions 
Hierarchical to: FTA_MCS.1 Basic limitation on multiple concurrent sessions 
Dependencies: FIA_UID.1 Timing of Identification 

16.2.7.1 FTA_MCS.2.1 

The TSF shall restrict the maximum number of concurrent sessions that belong to the same user according 
to the rules [assignment: rules for the number of maximum concurrent sessions]. 

16.2.7.2 FTA_MCS.2.2 

The TSF shall enforce, by default, a limit of [assignment: default number] sessions per user. 
16.3 Session locking (FTA_SSL) 
16.3.1 Family Behaviour 

This family defines requirements for the TSF to provide the capability for TSF-initiated and user-Initiated 
locking and unlocking of interactive sessions. 
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16.3.2 Component levelling 



FTA_SSL: Session locking 




Figure 80 - FTA_SSL component tevelling 

FTA_SSL.1 TSF-initiated session locking includes system initiated locking of an interactive session after a 
specified period of user Inactivity. 

FTA_SSL.2 User-initiated locking, provides capabilities for the user to lock and unlock the user's own 
Interactive sessions. 

FTA_SSL.3 TSF-initiated termination, provides rexiuirements for the TSF to terminate the session after a 
period of user Inactivity. 

16.3.3 Management of FTA_SSL.1 

The following actions could be considered for the management functions in FMT: 

a) specification of the time of user inactivity after which lock-out occurs for an individual user; 

b) specification of the default time of user inactivity after which lock-out occurs; 

c) management of the events that should occur prior to unlocking the session. 

16.3.4 Management of FTA_SSL.2 

The following actions could be considered for the management functions in FMT: 
a) management of the events that should occur prior to unlocking the session. 

16.3.5 Management of FTA_SSL.3 

The following actions could be considered for the management functions in FMT: 

a) specification of the time of user inactivity after which termination of the interactive session occurs for an 
individual user; 

b) specification of the default time of user inactivity after which termination of the interactive session occurs. 

16.3.6 Audit of FTA_SSL1, FTA_SSL.2 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: Locking of an interactive session by the session locking mechanism. 

b) Minimal: Successful unlocking of an interactive session. 

c) Basic: Any attempts at unlocking an interactive session. 
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16.3.7 Audit Of FTA_SSL.3 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: Termination of an interactive session by the session locking mechanism. 

16.3.8 FTA_SSL.1 TSF-initiated session locking 
Hierarchical to: No other components. 
Dependencies: FIA_UAU.1 Timing of authentication 

16.3.8.1 FTA_SSL1.1 

The TSF shall lock an interactive session after [assignment: time interval of user inactivity] by: 

a) clearing or overwriting display devices, making the current contents unreadable; 

b) disabling any activity of the user's data access/display devices other than unlocking the session. 

16.3.8.2 FTA_SSL.1.2 

The TSF shall require the following events to occur prior to unlocking the session: [assignment: 
events to occur]. 

16.3.9 FTA_SSL2 User-initiated locking 
Hierarchical to: No other components. 
Dependencies: FIA_UAU.1 Timing of authentication 
16.3.9.1 FTA_SSL.2,1 

The TSF shall allow user-initiated locking of the user's own interactive session, by: 

a) clearing or overwriting display devices, making the current contents unreadable; 

b) disabling any activity of the user's data access/display devices other than unlocking the session. 

1J6.3.9.2 FTA_SSL.2.2 

The TSF shall require the following events to occur prior to unlocking the session: [assignment: 
events to occur]. 

16.3.10 FTA_SSL.3 TSF-initiated termination 
Hierarchical to: No other components. 
Dependencies: No dependencies. 
16.3.10.1 FTA_SSL.3.1 

The TSF shall terminate an interactive session after a [assignment: time interval of user inactivity]. 
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16.4 TOE access banners (FTA_TAB) 

16.4.1 Family Behaviour 

This family defines requirements to display a configurable advisory warning message to users regarding the 
appropriate use of the TOE. 

16.4.2 Component levelling 



FTA TAB: TOE access banners 



Figure 81 - FTA_TAB component levelling 

FTA_TAB.1 Default TOE access banners, provides the requirement for a TOE Access Banner. This banner is 
displayed prior to the establishment dialogue for a session. 

16.4.3 Management of FTA_TAB.1 

The following actions could be considered for the management functions in FMT: 
a) maintenance of the banner by the authorised administrator. 

16.4.4 Audit Of FTA_TAB.1 

There are no auditable events foreseen. 

16.4.5 FTA_TAB.1 Default TOE access banners 
Hierarchical to: No other components. 
Dependencies: No dependencies. 

16.4.5.1 FTA_TAB.1.1 

Before establishing a user session, the TSF shall display an advisory warning message regarding 
unauthorised use of the TOE. 

16.5 TOE access history (FTA_TAH) 

16.5.1 Family Behaviour 

This family defines requirements for the TSF to display to a user, upon successful session establishment, a 
history of successful and unsuccessful attempts to access the user's account. 

16.5.2 Component levelling 



FTATAH: TOE access historj' 



Figure 82 - FTA_TAH component levelling 

FTA_TAH.1 TOE access history, provides the requirement for a TOE to display information related to previous 
attempts to establish a session. 

16.5.3 Management of FTA_TAH.1 

There are no management activities foreseen. 
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16.5.4 Audit of FTA_TAH.1 

There are no auditable events foreseen. 

16.5.5 FTA_TAH.1 TOE access history 
Hierarchical to: No other components. 
Dependencies; No dependencies. 

16.5.5.1 FTA_TAH.1.1 

Upon successful session establishment, the TSF shall display the [selection: date, f/me, method, 
location] of the last successful session establishment to the user. 

16.5.5.2 FTA_TAH.1.2 

Upon successful session establishment, the TSF shall display the [selection: date, time, method, 
location] of the last unsuccessful attempt to session establishment and the number of unsuccessful 
attempts since the last successful session establishment 

16.5.5.3 FTA_TAH.1.3 

The TSF shall not erase the access history information from the user interface without giving the user 
an opportunity to review the information. 

16.6 TOE session establishment (FTA_TSE) 

16.6.1 Family Behaviour 

This family defines requirements to deny a user permission to establish a session with the TOE. 

16.6.2 Component levelling 



FTA TSE: TOE session establishment 



Figure 83 - FTA_TSE component levelling 

FTA_TSE.1 TOE session establishment, provides requirements for denying users access to the TOE based 
on attributes. 

16.6.3 Management of FTA_TSE.1 

The following actions could be considered for the management functions in FMT: 

a) management of the session establishment conditions by the authorised administrator. 

16.6.4 Audit of FTA_TSE.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: Denial of a session establishment due to the session establishment mechanism. 

b) Basic: All attempts at establishment of a user session. 

c) Detailed: Capture of the value of the selected access parameters (e.g. location of access, time of access). 
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16.6.5 FTA_TSE.1 TQE session establishment 

Hierarchical to: No other components. 

Dependencies: No dependencies. 

16.6.5.1 FTA_TSE.1.1 

The TSF shall be able to deny session establishment based on [assignment: attributes]. 

17 Class FTP: Trusted path/channels 

Families in this class provide requirements for a trusted communication path between users and the TSF. and 
for a trusted communication channel between the TSF and other trusted IT products. Trusted paths and 
channels have the following general characteristics: 

• The communications path is constructed using internal and external communications channels (as 
appropriate for the component) that isolate an identified subset of TSF data and commands from the 
remainder of the TSF and user data. 

• Use of the communications path may be initiated by the user and/or the TSF (as appropriate for the 
component). 

• The communications path is capable of providing assurance that the user is communicating with 1he 
correct TSF, and that the TSF is communicating with the correct user (as appropriate for the component). 

In this paradigm, a trusted channel is a communication channel that may be initiated by either side of the 
channel, and provides non-repudiation characteristics with respect to the identity of the sides of the channel. 

A trusted path provides a means for users to perform functions through an assured direct interaction with the 
TSF. Trusted path is usually desired for user actions such as initial identification and/or authentication, but 
may also be desired at other times during a user's session. Trusted path exchanges may be initiated by a user 
or the TSF. User responses via the trusted path are guaranteed to be protected from modification by or 
disclosure to untrusted applications. 



FTP lTC:Inter-TSF trusted channel 



FTP TRP: Trusted path 



Figure 84 - FTP: Trusted path/channels class decomposition 
17.1 Inter-TSF trusted channel (FTPJTC) 

17.1.1 Family Behaviour 

This family defines requirements for the creation of a trusted channel between the TSF and other trusted IT 
products for the performance of security critical operations. This family should be included whenever there are 
requirements for the secure communication of user or TSF data between the TOE and other trusted IT 
products. 

17.1.2 Component levelling 



FTP ITC: Inter-TSF tnisted channel 



Figure 85 - FTPJTC component levelling 
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FTPJTC.1 Inter-TSF trusted channel, requires that the TSF provide a trusted communication channel 
between itself and another trusted IT product. 

17.1 .3 Management of FTPJTC.1 

The following actions could be considered for the management functions in FMT: 
a) Configuring the actions that require trusted channel, if supported. 

17.1.4 Audit of FTPJTC.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: Failure of the trusted channel functions. 

b) Minimal: Identification of the initiator and target of failed trusted ch^annel functions. 

c) Basic: All attempted uses of the trusted channel functions. 

d) Basic: Identification of the initiator and target of all trusted channel functions. 

17.1.5 FTPJTC.1 Inter-TSF trusted channel 
Hierarchical to: No other components. 
Dependencies: No dependencies. 

17.1.5.1 FTPJTC.t.1 

The TSF shall provide a communication channel between Itself and a remote trusted IT product tJiat is 
logically distinct from other communication channels and provides assured identification of its end 
points and protection of the channel data from modification or disclosure. 

17.1.5.2 FTPJTC.1. 2 

The TSF shall permit [selection: the TSF, the remote trusted tT producf\ to initiate communication via 
the trusted channel. 

17.1.5.3 FTPJTC.1. 3 

The TSF shall initiate communication via the trusted channel for [assignment: list of functions for 
which a trusted channel is required^. 

17.2 Trusted path (FTP_TRP) 

17.2.1 Family Behaviour 

This family defines the requirements to establish and maintain trusted communication to or from users and the 
TSF. A trusted path may be required for any security-relevant interaction. Trusted path exchanges may be 
initiated by a user during an interaction with the TSF, or the TSF may establish communication with the user 
via a trusted path. 
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17.2.2 Component levelling 



FTP_TRP: Trasted path 



Figure 86 - FTP_TRP component levelling 

FTP_TRP.1 Trusted path, requires that a trusted path between the TSF and a user be provided for a set of 
events defined by a PP/ST author. The user and/or the TSF may have the ability to initiate the trusted path. 

17.2.3 Management of FTP_TRP.1 

The following actions could be considered for the management functions in FMT: 
a) Configuring the actions that require trusted path, if supported. 

17.2.4 Audit Of FTP_TRP.1 

The following actions should be auditable if FAU_GEN Security audit data generation is included in the 
PP/ST: 

a) Minimal: Failures of the trusted path functions. 

b) Minimal: Identification of the user associated with all trusted path failures, if available. 

c) Basic: All attempted uses of the trusted path functions. 

d) Basic: Identification of the user associated with all trusted path invocations, if available. 

17.2.5 FTP_TRP.1 Trusted path 
Hierarchical to: No other components. 
Dependencies: No dependencies. 

17.2.5.1 FTP_TRP.1.1 

The TSF shall provide a communication path between itself and [selection: remote, local] users that is 
logically distinct from other communication paths and provides assured identification of its end 
points and protection of the communicated data from modification or disclosure. 

17.2.5.2 FTP_TRP.1.2 

The TSF shall permit [selection: the TSF, local asers, remote users] to initiate communication via the 
trusted path. 

17.2.5.3 FTP_TRP.1.3 

The TSF shall require the use of the trusted path for [selection: initial user 
authentication,[assignment: other services for which trusted path is required]]. 
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Annex A 

(normative) 

Security functional requirements application notes 



This annex contains additional guidance for the families and components defined in the elements of this part 
of ISO/IEC 15408, which may be required by users, developers or evaluators to use the components. To 
facilitate finding the appropriate information, the presentation of the classes, families and components in this 
annex Js similar to the presentation within the elements. 

A.1 Structure of the notes 

This clause defines the content and presentation of the notes related to functional requirements of ISO/IEC 
15408. 

A. 1.1 Class structure 

Figure A.I below illustrates the functional class structure in this annex. 



Functional 
Class 



Key 

The Functional Class 
can contain multiple 
Functional Families. 



Class 
Name 



Class 
Introduction 



Functional 
Families 



Figure A.I - Functional class structure 
A.1.1.1 Class name 

This is the unique name of the class defined within the normative elements of this part of ISO/IEC 15408. 

A.1.1.2 Class introduction 

The class introduction in this annex provides information about the use of the families and components of the 
class. This information is completed with the informative diagram that describes the organisation of each class 
with the families in each class and the hierarchical relationship between components in each family. 

A. 1.2 Family structure 

Figure A.2 illustrates the functional family structure for application notes in diagrammatic form. 
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Functional 
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Evaluator notes 
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Figure A.2 - Functional family structure for application notes 
A.1.2.1 Family name 

This is the unique name of the family defined within the normative elements of this part of ISO/IEC 15408. 
A.1.2.2 User notes 

The user notes contain additional information that is of interest to potential users of the family, that is PP, ST 
and functional package authors, and developers of TOEs incorporating the functional components. The 
presentation is informative, and might cover warnings about limitations of use and areas where specific 
attention might be required when using the components. 

A.1 .2.3 Evaluator notes 

The evaluator notes contain any information that is of interest to developers and evaluators of TOEs that claim 
compliance with a component of the family. The presentation is informative and can cover a variety of areas 
where specific attention might be needed when evaluating the TOE. This can include clarifications of meaning 
and specification of the way to interpret requirements, as well as caveats and warnings of specific interest to 
evaluators. 

These User Notes and Evaluator Notes subclauses are not mandatory and appear only if appropriate. 

A.I. 3 Component structure 

Figure A. 3 illustrates the functional component structure for the application notes. 
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Figure A.3 - Functional component structure 
A.I. 3.1 Component Identification 

This is the unique name of the component defined within the normative elements of this part of ISO/IEC 15408. 
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A.1 .3.2 Component rationale and application notes 

Any specific information related to the component can be found In this subclause. 

• The rationale contains the specifics of the rationale that refine the general statements on rationale for the 
specific level, and should only be used If level specific amplification is required. 

• The application notes contain additional refinement in terms of narrative qualification as It pertains to a 
specific component. This refinement can pertain to user notes, and/or evaluator notes as described In 
Subclause A.1.2. This refinement can be used to explain the nature of the dependencies (e.g. shared 
information, or shared operation). 

This subclause is not mandatory and appears only if appropriate. 

A.1.3.3 Permitted operations 

This portion of each component contains advice relating to the permitted operations of the component. 

This subclause is not mandatory and appears only If appropriate. 

A.2 Dependency tables 

The following dependency tables for functional components show their direct, Indirect and optional 
dependencies. Each of the components that is a dependency of some functional component is allocated a 
column. Each functional component is allocated a row. The value In the table cell Indicate whether the column 
label component Is directly required (Indicated by a cross "X"), Indirectly required (Indicated by a dash "-"), or 
optionally required (indicated by a "o") by the row label component. An example of a component with optional 
dependencies Is FDP_ETC.1 Export.of user data without security attributes, which requires either FDP_ACC.1 
Subset access control or FDPJFG.1 Subset information flow control to be present. So if FDP_ACC.1 Subset 
access control is present, FDP_IFC.1 Subset information flow control is not necessary and vice versa. If no 
character is presented, the component is not dependent upon another component. 
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Table A.1 Dependency table for Class FAU: Security audit 
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Table A.2 Dependency table for Class FCO: Communication 
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Table A.3 Dependency table for Class FCS: Cryptographic support 
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Table A.4 Dependency table for Class FDP: User data protection 
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Table A.6 Dependency table for Class FIA: Identification and authentication 
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Table A.6 Dependency table for Class FMT: Security management 
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Table A.7 Dependency table for Class FPR: Privacy 
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Table A.8 Dependency table for Class FPT: Protection of the TSF 
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Table A.9 Dependency table for Class FRU: Resource utilisation 
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Table A. 10 Dependency table for Class FTA: TOE access 
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Annex B 

(normative) 

Functional classes, families, and components 



The following Annex C through Annex M provide the application notes for the functional classes defined in the 
main body of this part of ISO/IEC 15408. 
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Annex C 

(normative) 

Class FAU: Security audit 



ISO/IEC 15408 audit families aliow PP/ST authors the ability to define requirements for monitoring user 
activities and, in some cases, detecting real, potential, or imminent violations of the TSP. The TOE's security 
audit functions are defined to help monitor security-relevant events, and act as a deterrent against security 
violations. The requirements of the audit families refer to functions that include audit data protection, record 
format, and event selection, as well as analysis tools, violation alarms, and real-time analysis. The audit trail 
should be presented in human-readable format either directly (e.g. storing the audit trail in human-readabie 
format) or indirectly (e.g. using audit reduction tools), or both. 

While developing the security audit requirements, the PP/ST author should lake note of the inter-relationships 
among the audit families and components. The potential exists to specify a set of audit requirements that 
comply with the family/component dependencies lists, while at the same time resulting in a deficient audit 
function (e.g. an audit function that requires all security relevant events to be audited but without the selectivity 
to control them on any reasonable basis such as individual user or object). 

C.I Audit requirements in a distributed environment 

The implementation of audit requirements for networks and other large systems may differ significantly from 
those needed for stand-alone systems. Larger, more complex and active systems require more thought 
concerning which audit data to collect and how this should be managed, due to lowered feasibility of 
interpreting (or even storing) what gets collected. The traditional notion of a time-sorted list or "trail" of audited 
events may not be applicable in a global asynchronous network with arbitrarily many events occurring at once. 

Also, different hosts and servers on a distributed TOE may have differing naming policies and values. 
Symbolic names presentation for audit review may require a net-wide convention to avoid redundancies and 
"name clashes." 

A multi-object audit repository, portions of which are accessible by a potentially wide variety of authorised 
users, may be required if audit repositories are to serve a useful function in distributed systems. 

Finally, misuse of authority by authorised users should be addressed by systematically avoiding local storage 
of audit data pertaining to administrator actions. 

Figure C.1 shows the decomposition of this class into its constituent components. 
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FAU_ARP: Security audit automatic response 



FAU_OEN: Security audit data generation 



FAU_SAA: Security audit analysis 



FAUSAR: Security audit review 



FAU_SEL: Security audit event selection 



FAU_STO; Security audit event storage 
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Figure C.I - FAU: Security audit class decomposition 

C.2 Security audit automatic response (FAU_ARP) 

C.2.1 Application notes 

The Security audit automatic response family describes requirements for the handling of audit events. The 
requirement could include requirements for alarms or TSF action (automatic response). For example, the TSF 
could include the generation of real time alarms, termination of the offending process, disabling of a service, 
or disconnection or invalidation of a user account. 

An audit event is defined to be an "potential security violation" if so indicated by the Security audit analysis 
(FAU_SAA) components. 

C.2.2 FAU_ARP.1 Security alarms 

C.2.2.1 User application notes 

An action should be taken for follow up action in the event of an alarm. This action can be to inform the 
authorised user, to present the authorised user with a set of possible containment actions, or to take 
corrective actions. The timing of the actions should be carefully considered by the PP/ST author. 

C.2.2.2 Operations 

C.2.2.2.1 Assignment 

In FAU_ARP.1.1, the PP/ST author should specify the actions to be taken in case of a potential security 
violation. An example of such a list is: "inform the authorised user, disable the subject that created the 
potential security violation." It can also, specify that the action to be taken can be specified by an authorised 
user. 
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C.3 Security audit data generation (FAU_GEN) 

C.3.1 Application notes 

The Security audit data generation family includes requirements to specify the audit events that should be 
generated by the TSF for security-relevant events. 

This family is presented in a manner that avoids a dependency on all components requiring audit support. 
Each component has an audit subclause developed in which the events to be audited for that functional area 
are listed. When the PP/ST author assembles the PP/ST, the items In the audit area are used to complete the 
variable in this component. Thus, the specification of what could be audited for a functional area is localised in 
that functional area. 

The list of auditable events is entirely dependent on the other functional families within the PP/ST. Each family 
definition should therefore include a list of its family-specific auditable events. Each auditable event in the list 
of auditable events specified in the functional family should correspond to one of the levels of audit event 
generation specified in this family (i.e. minimal, basic, detailed). This provides the PP/ST author with 
information necessary to ensure that all appropriate auditable events are specified in the PP/ST. The following 
example shows how auditable events are to be specified in appropriate functional families: 

"The following actions should be auditable if Security audit data generation (FAU_GEN} is included in the 
PP/ST: 

a) Minimal: Successful use of the user security attribute administration functions; 

b) Basic: All attempted uses of the user security attribute administration functions; 

c) Basic: Identification of which user security attributes have been modified; 

d) Detailed: With the exception of specific sensitive attribute data items (e.g. passwords, cryptographic keys), 
the new values of the attributes should be captured." 

For each functional component that is chosen, the auditable events that are Indicated in that component, at 
and below the level indicated in Security audit data generation (FAU_GEN) should be auditable. If, for 
example, in the previous example "Basic" would be selected in Security audit data generation (FAU_GEN), 
the auditable events mentioned in a), b) and c) should be auditable. 

Observe that the categorisation of auditable events is hierarchical. For example, when Basic Audit Generation 
is desired, all auditable events identified as being either Minimal or Basic, should also be included in the 
PP/ST through the use of the appropriate assignment operation, except when the higher level event simply 
provides more detail than the lower level event. When Detailed Audit Generation is desired, all identified 
auditable events (Minimal, Basic, and Detailed) should be included in the PP/ST. 

A PP/ST author may decide to include other auditable events beyond those required for a given audit level. 
For example, the PP/ST may claim only minimal audit capabilities while including most of the basic 
capabilities because the few excluded capabilities conflict with other PP/ST constraints (e.g. because they 
require the collection of unavailable data). 

The functionality that creates the auditable event should be specified in the PP or ST as a functional 
requirement. 

The following are examples of the types of the events that should be defined as auditable within each PP/ST 
functional component: 

a) Introduction of objects within the TSC into a subject's address space; 

b) Deletion of objects; 

c) Distribution or revocation of access rights or capabilities; 



127 



IS 14990 (Part 2) : 2006 
ISO/IEC 15408-2 : 2005 

d) Changes to subject or object security attributes; 

e) Policy checks performed by the TSF as a result of a request by a subject; 

f) The use of access rights to bypass a policy check; 

g) Use of Identification and Authentication functions; 

h) Actions taken by an operator, and/or authorised user (e.g. suppression of a TSF protection mechanism as 
human-readable labels); 

i) Import/export of data from/to removable media (e.g. printed output, tapes, diskettes). 

C.3.2 FAU_GEN.1 Audit data generation 

C.3.2.1 User application notes 

This component defines requirements to identify the auditable events for which audit records should be 
generated, and the information to be provided in the audit records. 

FAU_GEN.1 Audit data generation by itself might be used when the TSP does not require that individual user 
identities be associated with audit events. This could be appropriate when the PP/ST also contains privacy 
requirements. If the user identity must be incorporated FAU_GEN.2 User identity association could be used in 
addition. 

C.3.2.2 Evaluator notes 

There is a dependency on Time stamps (FPT_STM). If con^ectness of time is not an issue for this TOE, 
elimination of this dependency could be justified. 

C.3.2.3 Operations 

C.3.2.3.1 Selection 

In FAU_GEN.1.1, the PP/ST author should select the level of auditable events called out in the audit 
subclause of other functional components included in the PP/ST. This level is one of the following: "minimum", 
"basic", "detailed" or "not specified". 

C.3.2.3.2 Assignment 

In FAU_GEN.1.1, the PP/ST author should assign a list of other specifically defined auditable events to be 
included in the list of auditable events. The assignment may comprise none, or events that could be auditable 
events of a functional requirement that are of a higher audit level than requested in b), as well as the events 
generated through the use of a specified Application Programming Interface (API). 

Inf AU_GEN.1.2, the PP/ST author should assign, for each auditable events included in the PP/ST, either a 
list of other audit relevant information to be included in audit events records or none. 

C.3^ FAU_GEN.2 User identity association 

C.3.3.1 User application notes 

This component addresses the requirement of accountability of auditable events at the level of individual user 
identity. This component should be used in addition to FAU_GEN.1 Audit data generation. 

There is a potential conflict between the audit and privacy requirements. For audit purposes it may be 
desirable to know who performed an action. The user may want to keep his/her actions to himself/herself and 
not be identified by other persons (e.g. a site with job offers). Or it might be required in the Organisational 
Security Policy that the idenfity of the users must be protected. In those cases the objectives for audit and 
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privacy might contradict each other. Therefore if this requirement is selected and privacy is important, 
inclusion of the component user pseudonimity might be considered. Requirements on determining the real 
user name based on its pseudonym are specified in the privacy class. 

C.4 Security audit analysis (FAU_SAA) 

C.4.1 Application notes 

This family defines requirements for automated means that analyse system activity and audit data looking for 
possible or real security violations. This analysis may work in support of intrusion detection, or automatic 
response to an imminent security violation. 

The action to be performed by the TSF on detection of a possible fmn>lnent or potential violation is defined in 
Security audit automatic response (FAU_ARP) components. 

For real-time analysis, audit data could be transformed into a useful format for automated treatment, but into a 
different useful format for delivery to authorised users for review. 

C.4.2 FAU„SAA.1 Potential violation analysis 

C. 4.2.1 User application notes 

This component is used to specify the set of auditable events whose occurrence or accumulated occurrence 
held to indicate a potential violation of the TSP, and any rules to be used to perform the violation analysis. 

C.4.2.2 Operations 

C.4.2.2.1 Assignment 

In FAU_SAA.1.2, the PP/ST author should identify the subset of defined auditable events whose occurrence 
or accumulated occurrence need to be detected as an indication of a potential violation of the TSP. 

In FAU_SAA.1.2, the PP/ST author should specify any other rules that the TSF should use in its analysis of 
the audit trail. Those rules could include specific requirements to express the needs for the events to occur in 
a certain period of time (e.g. period of the day, duration). If there are no additional rules that the TSF should 
use in the analysis of the audit trail, this assignment can be completed with "none". 

C.4.3 FAU_SAA.2 Profile based anomaly detection 
C.4.3.1 User application notes 

A profile is a structure that characterises the behaviour of users and/or subjects; it represents how the 
users/subjects interact with the TSF in a variety of ways. Patterns of usage are established with respect to the 
various types of activity the users/subjects engage in (e.g. patterns in exceptions raised, patterns in resource 
utilisation (when, which, how), patterns in actions performed). The ways in which the various types of activity 
are recorded in the profile (e.g. resource measures, event counters, timers) are referred to as profile metrics. 

Each profile represents the expected patterns of usage performed by members of the profile target group. 
This pattern may be based on past use (historical patterns) or on normal use for users of similar target groups 
(expected behaviour). A profile target group refers to one or more users who interact with the TSF. The 
activity of each member of the profile group is used by the analysis tool in establishing the usage patterns 
represented in the profile. The following are some examples of profile target groups: 

a) Single user account: one profile per user; 

b) Group ID or Group Account: one profile for all users who possess the same group ID or operate using 
the same group account; 

c) Operating Role: one profile for all users sharing a given operating role; 

d) System: one profile for all users of a system. 
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Each member of a profile target group is assigned an Individual suspicion rating that represents how closely 
that member's new activity corresponds to the established patterns of usage represented in the group profile. 

The sophistication of the anomaly detection tool will largely be determined by the number of target profile 
groups required by the PP/ST and the complexity of the required profile metrics. 

This component is used to specify the set of auditable events whose occurrence or accumulated occurrence 
indicates a potential violation of the TSP, and any rules to be used to perform the violation analysis. This set 
of events or rules could be modified by the authorised user, through addition, modification or deletion of 
events or rules. 

The PP/ST author should enumerate specifically what activity should be monitored and/or analysed by the 
TSF. The PP/ST author should also identify specifically what information pertaining to the activity is necessary 
to construct the usage profiles. 

FAU_SAA.2 Profile based anomaly detection requires that the TSF maintain profiles of system usage. The 
word maintain implies that the anomaly detector is actively updating the usage profile based on new activity 
performed by the profile target members. It is important here that the metrics for representing user activity are 
defined by the PP/ST author. For example, there may be a thousand different actions an individual may be 
capable of performing, but the anomaly detector may choose to monitor a subset of that activity. Anomalous 
activity gets integrated into the profile just like non-anomalous activity (assuming the tool is monitoring those 
actions). Things that may have appeared anomalous four months ago. might over time become the norm (and 
vice-versa) as the user's work duties change. The TSF wouldn't be able to capture this notion if it filtered out 
anomalous activity from the profile updating algorithms. 

Administrative notification should be provided such that the authorised user understands the significance of 
the suspicion rating. 

The PP/ST author should define how to interpret suspicion ratings and the conditions under which anomalous 
activity is indicated to the Security audit automatic response (FAU_ARP) mechanism. 

C.4.3.2 Operations 

CA3.2.1 Assrgnment 

In FAU_S/^A.2.1, the PP/ST author should specify the profile target group. A single PP/ST may include 
multiple profile target groups. 

In FAU_SAA.2.3, the PP/ST author should specify conditions under which anomalous activity is reported by 
the TSF. Conditions may include the suspicion rating reaching a certain value, or be based on the type of 
anomalous activity observed. 

C.4.4 FAU_SAA.3 Simple attack heuristics 

C.4.4.1 User application notes 

In practice, it is at best rare when an analysis tool can detect with certainty when a security violation is 
imminent. However, there do exist some system events that are so significant that they are always worthy of 
Independent review. Example of such events Include the deletion of a key TSF security data file (e^g. the 
password file) or activity such as a remote user attempting to gain administrative privilege. These events are 
referred to as signature events in that their occurrence in isolation from the rest of the system activity are 
indicative of intrusive activity. 

The complexity of a given tool will depend greatly on the assignments defined by the PP/ST author in 
identifying the base set of signature events. 
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The PP/ST author should enumerate specifically what events should be monitored by the TSF in order to 
perform the analysis. The PP/ST author should identify specifically what information pertaining to the event is 
necessary to detemnine if the event maps to a signature event. 

Administrative notification should be provided such that the authorised user understands the significance of 
the event and the appropriate possible responses. 

An effort was made in the specification of these requirements to avoid a dependency on audit data as the sole 
input for monitonng system activity. This was done in recognition of the existence of previously developed 
intrusion detection tools that do not perform their analyses of system activity solely through the use of audit 
data (examples of other input data include network datagrams, resource/accounting data, or combinations of 
various system data). 

The elements of FAU_SAA.3 Simple attack heuristics do not require that the TSF implementing the immediate 
attack heunstics be the same TSF whose activity is being monitored. Thus, one can develop an intrusion 
detection component that operates independently of the system whose system activity is being analysed. 

C.4.4.2 Operations 
C.4.4.2.1 Assignment 

In FAU_SAA.3.1. the PP/ST author should identify a base subset of system events whose occurrence in 
isolation from all other system activity, may indicate a violation of the TSP. These include events that' by 
themselves indicate a clear violation to the TSP, or whose occurrence is so significant that they warrant 
actions. 

In FAU_SAA.3.2, the PP/ST author should specify the information used to determine system activity This 
information is the input data used by the analysis toot to determine the system activity that has occurred on 
the TOF. This data may include audit data, combinations of audit data with other system data or may consist 
of data other than the audit data. The PP/ST author should define precisely what system events and event 
attnbutes are being monitored within the input data. 

C.4.5 FAU_SAA.4 Complex attack heuristics 
C.4.5.1 User application Tiotes 

In practice, it is at best rare when an analysis tool can detect with certainty when a security violation is 
imminent. However, there do exist some system events that are so significant they are always worthy of 
independent review. Example of such events include the deletion of a key TSF security data file (eg the 
password file) or activity such as a remote user attempting to gain administrative privilege. These events are 
refen-ed to as signature events in that their occurrence in isolation from the rest of the system activity are 
indicative of intrusive activity. Event sequences are an ordered set of signature events that might indicate 
intrusive activity. " 

The complexity of a given tool will depend greatly on the assignments defined by the PP/ST author in 
identifying the base set of signature events and event sequences. 

The PP/ST author should define a base set of signature events and event sequences to be represented by the 
TSF. Additional signature events and event sequences may be defined by the system developer. 

The PP/ST author should enumerate specifically what events should be monitored by the TSF in order to 
perform the analysis. The PP/ST author should identify specifically what information pertaining to the event is 
necessary to determine if the event maps to a signature event. 

/\dministrative notification should be provided such that the authorised user understands the significance of 
the event and the appropriate possible responses. 

An effort was made in the specification of these requirements to avoid a dependency on audit data as the sole 
input for monitonng system activity. This was done in recognition of the existence of previously developed 
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intrusion detection tools that do not perform their analyses of system activity solely through the use of audit 
data (examples of other input data include network datagrams, resource/accounting data, or combinations of 
various system data). Levelling, therefore, requires the PP/ST author to specify the type of input data used to 
monitor system activity. 

The elements of FAU_SAA.4 Complex attack heuristics do not require that the TSF implementing the complex 
attack heuristics be the same TSF whose activity is being monitored. Thus, one can develop an intrusion 
detection component that operates independently of the system whose system activity is being analysed. 

C.4.5.2 Operations 

C.4.5.2.1 Assignment 

In FAU_SAA,4.1, the PP/ST author should identify a base set of list of sequences of system events whose 
occurrence are representative of known penetration scenarios. These event sequences represent known 
penetration scenarios. Each event represented in the sequence should map to a monitored system event, 
such that as the system events are performed, they are bound (mapped) to the known penetration event 
sequences. 

In FAU_SAA.4.1, the PP/ST author should identify a base subset of system events whose occurrence, in 
isolation from all other system activity, may indicate a violation of the TSP. These include events that by 
themselves indicate a clear violation to the TSP, or whose occurrence is so significant they warrant action. 

In FAU_SAA.4.2, the PP/ST author should specify the information used to determine system activity. This 
information is the input data used by the analysis tool to determine the system activity that has occun'ed on 
the TOE. This data may include audit data, combinations of audit data with other system data, or may consist 
of data other than the audit data. The PP/ST author should define precisely what system events and event 
attributes are being monitored within the input data. 

C.5 Security audit review (FAU_SAR) 
C.5.1 Application notes 

The Security audit review family defines requirements related to review of the audit information. 

These functions should allow pre-storage or post-storage audit selection that includes, for example, the ability 
to selectively review: 

• the actions of one or more users (e.g. identification, authentication, TOE entry, and access control 
actions); 

• the actions performed on a specific object or TOE resource; 

• alt of a specified set of audited exceptions; or 

• actions associated with a specific TSP attribute. 

The distinction between audit reviews is based on functionality. Audit review (only) encompasses the ability to 
view audit data. Selectable review is more sophisticated, and requires the ability to perform searches based 
on a single criterion or multiple criteria with logical (i.e. and/or) relations, sort audit data, filter audit tlata, 
before audit data are reviewed. 
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C.5.2 FAU_SAR.1 Audit review 

C.S.2.1 Rationale 

This component will provide authorised users the capability to obtain and interpret the information. In case of 
human users this information needs to be in a human understandable presentation. In case of external IT 
entities the information needs to be unambiguously represented in an electronic fashion. 

C. 5.2.2 User application notes 

This component is used to specify that users and/or authorised users can read the audit records. These audit 
records will be provided in a manner appropriate to the user. There are different types of users (human users, 
machine users) that might have different needs. 

The content of the audit records that can be viewed can be specified. 

C.5.2.3 Operations 

C.5.2.3.1 Assignment 

In FAU_SAR.1.1, the PP/ST author should specify the authorised users that can use this capability. If 
appropriate the PP/ST author may include security roles (see FMT_SMR.1 Security roles). 

In FAU_SAR.1.1, the PP/ST author should specify the type of information the specified user is permitted to 
obtain from the audit records. Examples are "all", "subject identity", "ail information belonging to audit records 
referencing this user". 

C.5.3 FAU_SAR.2 Restricted audit review 

C.S.3.1 User application notes 

This component specifies that any users not identified in FAU_SAR.1 Audit review will not be able to read the 
audit records. 

C.5.4 FAU_SAR.3 Selectable audit review 

C.5.4.1 User application notes 

This component is used to specify that it should be possible to perform selection of the audit data to be 
reviewed. If based on multiple criteria, those criteria should be related together with logical (i.e. "and" or "or") 
relations, and the tools should provide the ability to manipulate audit data (e.g. sort, filter). 

C^.4.2 Operations 

C.5.4.2.1 Selection 

In FAU_SAR.3.1, the PP/ST author should select whether searches, sorting and/or ordering can be performed 
by the TSF. 

C. 5.4.2. 2 Assignment 

In FAU_SAR.3.1, the PP/ST author should assign the criteria, possibly with logical relations, to be used to 
select the audit data for review. The logical relations are intended to specify whether the operation can be on 
an individual attribute or a collection of attributes. An example of this assignment could be: "application, user 
account and/or location". In this case the operation could be specified using any combination of the three 
attributes: application, user account and location. 
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C.6 Security audit event selection (FAU_SEL) 

C.6.1 Application notes 

The Security audit event selection family provides requirements related to the capabilities of identifying which 
of the possible auditable events are to be audited. The auditable events are defined in the Security audit data 
generation (FAU_GEN) family, but those events should be defined as being selectable in this component to 
be audited. 

This family ensures that it is possible to keep the auditirail from becoming so large that it becomes useless, 
by defining the appropriate granularity of the selected security audit events. 

C.6.2 FAU_SEL.1 Selective audit 

C.6.2.1 User application notes 

This component defines the criteria used for the selection of events to be audited. Those criteria could permit 
inclusion or exclusion of events from the set of auditable events, based on user attributes, subject attributes, 
objects attributes, or event types. 

The existence of individual user identities is not assumed for this component. This allows for TOEs such as 
routers that may not support the notion of users. 

For a distributed environment, the host identity could be used as a selection criteria for events to be audited. 

The management function FMT_MTD.1 Management of TSF data will handle the rights of authorised users to 
query or modify the selections. 

C.6.2.2 Operations 

C.6.2.2.1 Selection 

In FAU_SEL.1.1, the PP/ST author should select whether the security attributes upon which audit selectivity is 
based, is related to object identity, user identity, subject identity, host identity, or event type. 

C.6.2.2.2 Assignment 

In FAU_SEL.1.1, the PP/ST author should specify any additional attributes upon which audit selectivity is 
based. If there are no additional rules upon which audit selectivity is based, this assignment can be completed 
with "none". 

C.7 Security audit event storage (FAU_STG) 

C.7.1 Application notes 

The Security audit event storage family describes requirements for storing audit data for later use, Including 
requirements controlling the loss of audit information due to system failure, attack and/or exhaustion of 
storage space. 

C.7.2 FAU_STG.1 Protected audit trail storage 

C.7.2.1 User application notes 

In a distributed environment, as the location of the audit trait is in the TSC, but not necessarily co-located with 
the function generating the audit data, the PP/ST author could request authentication of the originator of the 
audit record, or non-repudiation of the origin of the record prior storing this record in the audit trail. 



134 



IS 14990 (Part 2): 2006 
ISO/IEC 15408-2: 2005 

The TSF will protect the audit trait from unauthorised deletion and modification. It is noted that in some 
systems the auditor (role) might not be authorised to delete the audit records for a certain period of time. 

C.7.2.2 Operations 

C.7.2.2.1 Selection 

In FAU_STG.1.2, the PP/ST author should specify whether the TSF shall prevent or only be able to detect 
modifications of the audit trail. Only one of these options may be chosen. 

C.7.3 FAU_STG.2 Guarantees of audit data availability 
C .7.3.1 User application notes 

This component allows the PP/ST author to specify to which metrics the audit trail should conform. 

In a distributed environment, as the location of the audit trail is in the TSC, but not necessarily co-located with 
the function generating the audit data, the PP/ST author could request authentication of the originator of the 
audit record, or non-repudiation of the origin of the record prior storing this record in the audit trail. 

C. 7.3.2 Operations 

C.7.3.2.1 Selection 

In FAU_STG.2.2, the PP/ST author should specify whether the TSF shall prevent or only be able to detect 
modifications of the audit trait. Only one of these options may be chosen. 

C.7.3.2.2 Assignment 

In FAU_STG.2.3, the PP/ST author should specify the metric that the TSF must ensure with respect to the 
audit trail. This metric limits the data loss by enumerating the number of records that must be kept, or the time 
that records are guaranteed to be maintained. An example of the metric could be "100,000" indicating that 
100,000 audit records can be stored. 

C.7.3.2.3 Selection 

In FAU_STG.2.3, the PP/ST author should specify the condition under which the TSF shall still be able to 
maintain a defined amount of audit data. This condition can be any of the following: audit storage exhaustion, 
failure, attack. 

C.7.4 FAU_STG.3 Action in case of possible audit data loss 

C.7.4.1 User application notes 

This component requires that actions will be taken when the audit trail exceeds certain pre-defined limits. 

C.7.4.2 Operations 

C.7.4.2.1 Assignment 

In FAU_STG.3.1 , the PP/ST author should indicate the pre-defined limit. If the management functions indicate 
that this number might be changed by the authorised user, this value is the default value. The PP/ST author 
might choose to let the authorised user define this limit. In that case the assignment can be for example "an 
authorised user set limit". 

In FAU_STG.3.1, the PP/ST author should specify actions that should be taken in case of imminent audit 
storage failure indicated by exceeding the threshold. Actions might include informing an authorised user. 
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C.7.5 FAU_STG.4 Prevention of audit data loss 

C.7.5.1 User application notes 

This component specifies the behaviour of the TOE if the audit trail is full: either audit records are ignored, or 
the TOE is frozen such that no auditable events can take place. The requirement also states that no matter 
how the requirement is instantiated, the authorised user with specific rights to this effect, can continue to 
generate auditable events (actions). The reason is that otherwise the authorised user could not even reset the 
system. Consideration should be given to the choice of the action to be taken by the TSF in the case of audit 
storage exhaustion, as ignoring events, which provides better availability of the TOE, will also permit actions 
to be performed without being recorded and without the user being accountable. 

C.7.5.2 Operations 

C.7.5.2.1 Selection 

In FAU_STG.4.1 , the PP/ST author should select whether the TSF shall Ignore auditable actions, or whether it 
should prevent auditable actions from happening, or whether the oldest audit records should be overwritten 
when the TSF can no longer store audit records. Only one of these options may be chosen. 

C.7.5.2.2 Assignment 

In FAU_STG.4.1, the PP/ST author should specify other actions that should be taken In case of audit storage 
failure, such as informing the authorised user. If there is no other action to be taken in case of audit storage 
failure, this assignment can be completed with "none". 
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Annex D 

(normative) 

Class FCO: Communication 



This class describes requirements specifically of interest for TOEs that are used for the transport of 
information. Families within this class deal with non-repudiation. 

In this class the concept of "information" is used. This information should be interpreted as the object being 
communicated, and could contain an electronic mail message, a file, or a set of predefined attribute types. 

In the literature, the terms "proof of receipt" and "proof of origin" are commonly used terms. However it is 
recognised that the term "proof might be interpreted in a legal sense to imply a form of mathematical rationale. 
The components In this class interpret the de-facto use of the word "proof in the context of "evidence" that the 
TSF demonstrates the non-repudiated transport of types of information. 

Figure D.1 shows the decomposition of this class into its constituent components. 



FCONRO: Non-repudiation of origin 



FGONRR: Non-reptidiation of receipt 



Figure D.I - FCO: Communication class decomposition 

D.I Non-repudiation of origin (FCO_NRO) 

D.1.1 User notes 

Non-repudiation of origin defines requirements to provide evidence to users/subjects about the identity of the 
originator of some information. The originator cannot successfully deny having sent the information because 
evidence of origin {e.g. digital signature) provides evidence of the binding between the originator and the 
information sent. The recipient or a third party can verify the evidence of origin. This evidence should not be 
forgeable. 

If the information or the associated attributes are altered in any way, validation of the evidence of origin might 
fail. Therefore a PP/ST author should consider including integrity requirements such as FDP_UIT.1 Data 
exchange integrity in the PP/ST. 

In non-repudiation there are several different roles involved, each of which could be combined in one or more 
subjects. The first role is a subject that requests evidence of origin (only in FC0_NR0.1 Selective proof of 
origin). The second role is the recipient and/or other subjects to which the evidence is provided (e.g. a notary). 
The third role is a subject that requests verification of the evidence of origin, for example, a recipient or a third 
party such as an arbiter 

The PP/ST author must specify the conditions that must be met to be able to verify the validity of the evidence. 
An example of a condition which could be specified is where the verification of evidence must occur within 24 
hours. These conditions, therefore, allow the tailoring of the non-repudiation to legal requirements, such as 
being able to provide evidence for several years. 

In most cases, the identity of the recipient will be the identity of the user who received the transmission. In 
some instances, the PP/ST author does not want the user identity to be exported. In that case the PP/ST 
author must consider whether it is appropriate to include this class, or whether the identity of the transport 
service provider or the identity of the host should be used. 
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In addition to (or instead of) the user identity, a PP/ST author might be more concerned about the time the 
information was transmitted. For example, requests for proposals must be transmitted before a certain date in 
order to be considered. In such instances, these requirements can be customised to provide a timestamp 
indication (time of origin). 

D.I. 2 FC0_NR0.1 Selective proof of origin 

D.I. 2.1 Operations 

D.1. 2.1.1 Assignment 

In FC0_NR0.1.1, the PP/ST author should fill in the types of information subject to the evidence of origin 
function, for example, electronic mail messages. 

D.I. 2.1. 2 Selection 

tn FC0_NR0.1.1, the PP/ST author should specify the user/subject who can request evidence of origin. 

D.I. 2.1. 3 Assignment 

In FC0_NR0.1.1, the PP/ST author, dependent on the selection, should specify the third parties that can 
request evidence of origin. A third party could be an arbiter, judge or legal body. 

in FC0_NR0.1.2, the PP/ST author should fill in the list of the attributes that shall be United to the information; 
for example, originator identity, time of origin, and location of origin. 

In FC0_NR0.1.2, the PP/ST author should fill in the list of information fields within the information over which 
the attributes provide evidence of origin, such as the body of a message. 

D.1.2.1.4 Selection 

In FC0_NR0.1.3, the PP/ST author should specify the user/subject who can verify the evidence of origin. 

D.1.2.1.5 Assignment 

In FC0_NR0.1.3, the PP/ST author should fill in the list of limitations under which the evidence can be 
verified. For example the evidence can only be verified within a 24 hour fime interval. An assignment of 
"immediate " or "indefinite" is acceptable. 

In FC0_NR0.1.3, the PP/ST author, dependent on the selection, should specify the third parties that can 
verify the evidence of origin. 

D.I. 3 FC0_NRb.2 Enforced proof of origin 

D.1.3.1 Operations 

D.I. 3.1.1 Assignment 

In FC0_NR0.2.1. the PP/ST author should fill in the types of information subject to the evidence of origin 
function, for example, electronic mail messages. 

In FCO_NR0.2.2, the PP/ST author should fill in the list of the attributes that shall be linked to the information; 
forexample, originator identity, time of origin, and location of origin. 

In FCO_NR0.2.2, the PP/ST author should fill in the list of information fields within the information over which 
the attributes provide evidence of origin, such as the body of a message. 
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D.I. 3.1. 2 Selection 

In FCO_NR0.2.3. the PP/ST author should specify the user/subject who can verify the evidence of origin. 
D.I. 3.1. 3 Assignment 

In FCO_NR0.2.3, the PP/ST author should fill in the list of limitations under which the evidence can be 
verified. For example the evidence can only be verified within a 24 hour time interval. An assignment of 
"immediate" or "indefinite" is acceptable. 

In FCO_NR0.2.3. the PP/ST author, dependent on the selection, should specify the third parties that can 
verify the evidence of origin. A third party could be an arbiter, judge or legal body. 

D.2 Non-repudiation of receipt (FCO_NRR) 
D.2.1 Usernotes 

Non-repudiation of receipt defines requirements to provide evidence to other users/subjects that the 
information was received by the recipient. The recipient cannot successfully deny having received the 
information because evidence of receipt (e.g. digital signature) provides evidence of the binding between the 
recipient attributes and the information. The originator or a third party can verify the evidence of receipt. This 
evidence should not be forgeable. 

It should be noted that the provision of evidence that the information was received does not necessarify imply 
that the information was read or comprehended, but only delivered 

If the information or the associated attributes are altered in any way, validation of the evidence of receipt with 
respect to the original information might fail. Therefore a PP/ST author should consider including integrity 
requirements such as FDP_UIT.1 Data exchange integrity in the PP/ST. 

in non-repudiation, there are several different roles involved, each of which could be combined in one or more 
subjects. The first role is a subject that requests evidence of receipt (only in FC0_NRR.1 Selective proof of 
receipt). The second role is the recipient and/or other subjects to which the evidence is provided, (e.g. a 
notary). The third role is a subject that requests verification of the evidence of receipt, for example, an 
originator or a third party such as an arbiter. 

The PP/ST author must specify the conditions that must be met to be able to verify the validity of the evidence. 
An example of a condition which could be specified is where the verification of evidence must occur within 24 
hours. These conditions, therefore, allow the tailoring of the non-repudiation to legal requirements, such as 
being able to provide evidence for several years. 

In most cases, the identity of the recipient will be the identity of the user who received the transmission. In 
some instances, the PP/ST author does not want the user identity to be exported. In that case, the PP/ST 
author must consider whether it is appropriate to include this class, or whether the identity of the transport 
service provider or the identity of the host should be used. 

In addition to (or instead of) the user identity, a PP/ST author might be more concerned about the time the 
information was received. For example, when an offer expires at a certain date, orders must be received 
before a certain date in order to be considered. In such instances, these requirements can be customised to 
provide a timestamp indication (time of receipt). 

D.2.2 FC0_NRR.1 Selective proof of receipt 

D.2.2.1 Operations 

D.2.2.1.1 Assignment 

In FC0_NRR.1.1, the PP/ST author should fill in the types of information subject to the evidence of receipt 
function, for example, electronic mail messages. 



139 



IS 14990 (Part 2) : 2006 
ISO/IEC 15408-2: 2005 

D.12.2.1.2 Selection 

In FC0_NRR.1 .1 , the PP/ST author should specify the user/subject who can request evidence of receipt. 

D.2.2.1.3 Assignment 

In FC0_NRR.1.1, the PP/ST author, dependent on the selection, should specify the third parties that can 
request evidence of receipt. A third party could be an arbiter, judge or legal body. 

In FC0_NRR.1 .2, the PP/ST author should fill in the list of the attributes that shall be linked to the information; 
for example, recipient identity, time of receipt, and location of receipt. 

In FC0_NRR.1.2, the PP/ST author should fill in the list of information fields with the fields within the 
information over which the attributes provide evidence of receipt, such as the body a message. 

D.2.2.1.4 Selection 

In FC0_NRR.1 .3, the PP/ST author should specify the user/subjects who can verify the evidence of receipt. 

D.2.2.1.5 Assignment 

In FC0_NRR.1.3, the PP/ST author should fill in the list of limitations under which the evidence can be verified. 
For example the evidence can only be verified within a 24 hour time interval. An assignment of "immediate" or 
"indefinite" is acceptable. 

In FC0_NRR.1.3, the PP/ST author, dependent on the selection, should specify the third parties that can 
verify the evidence of receipt. 

D.2.3 FC0_NRR.2 Enforced proof of receipt 

D.2.3.1 Operations 

D.2.3.1.1 Assignment 

In FC0_NRR.2.1, the PP/ST author should fill in the types of information subject to the evidence of receipt 
funcfion, for example electronic mail messages. 

In FCO_NRR.2.2, the PP/ST author should fill in the list of the attributes that shall be linked to the information; 
for example, recipient identity, time of receipt, and location of receipt. 

In FCO_NRR.2.2, the PP/ST author should fill in the list of information fields with the fields within the 
information over which the attributes provide evidence of receipt, such as the body of a message. 

D.2.3.1 .2 Selection 

In FCO_NRR.2.3, the PP/ST author should specify the user/subjects who can verify the evidence of receipt. 

D.2.3.1. 3 Assignment 

In FCO_NRR.2.3, the PP/ST author should fill in the list of limitations under which the evidence can be verified. 
For example the evidence can only be verified within a 24 hour time interval. An assignment of "immediate" or 
"indefinite" Is acceptable. 

In FCO_NRR.2.3, the PP/ST author, dependent on the selection, should specify the third parties that can 
verify the evidence of receipt. A third party could be an arbiter, judge or legal body. 
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Annex E 

(normative) 

Class FCS: Cryptographic support 



The TSF may employ cryptographic functionality to help satisfy several high-level security objectives. These 
include (but are not limited to): identification and authentication, non-repudiation, trusted path, trusted channel 
and data separation. This class is used when the TOE implements cryptographic functions, the 
implementation of which could be in hardware, firmware and/or software. 

The FCS: Cryptographic support class is composed of two families: Cryptographic key management 
(FCS_CKM) and Cryptographic operation (FCS_COP). The Cryptographic key management (FCS_CKM) 
family addresses the management aspects of cryptographic keys, while the Cryptographic operation 
{FCS_COP) family is concerned with the operational use of those cryptographic keys. 

For each cryptographic key generation method implemented by the TOE, if any, the PP/ST author should 
select thef CS_C4<M.1 Cryptographic key generation component. 

For each cryptographic key distribution method implemented by the TOE, if any, the PP/ST author should 
select the FCS_CKM.2 Cryptographic key distribution component. 

For each cryptographic key access method implemented by the TOE, if any, the PP/ST author should select 
the FCS_CKM.3 Cryptographic key access component. 

For each cryptographic key destruction method implemented by the TOE, if any, the PP/ST author should 
select the FCS_CKM.4 Cryptographic key destruction component. 

For each cryptographic operation (such as digital signature, data encryption, key agreement, secure hash, 
etc.) performed by the TOE, if any, the PP/ST author should select the FCS_C0P.1 Cryptographic operation 
component. 

Cryptographic functionality may be used to meet objectives specified in class FCO: Communication, and in 
families Data authentication (FDP_DAU), Stored data integrity (FDP_SDI), Inter-TSF user data confidentiality 
transfer protection (FDP_UCT), inter-TSF user data integrity transfer protection {FDP_UIT), Specification of 
secrets {FIA_SOS), User authentication (FIA_UAU), to meet a variety of objectives. In the cases where 
cryptographic functionality is used to meet objectives for other classes, the individual functional components 
specify the objectives that cryptographic functionality must satisfy. The objectives in class FCS: Cryptographic 
support should be used when cryptographic functionality of the TOE is sought by consumers. 

Figure E.1 shows the decomposition of this class into its constituent components. 
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FCS C'KM: Cryptographic key niaiiageivieiit 




PC'S COP: Ciyptograpliic operation 



Figure E.1 - FCS: Cryptographic support class decomposition 
E.1 Cryptographic key management (FCS_CKM) 

E.1.1 User notes 

Cryptographic keys must be managed throughout their lifetime. The typical events in the lifecycle of a 
cryptographic key include (but are not limited to): generation, distribution, entry, storage, access (e.g. backup, 
escrow, archive, recovery) and destruction. 

The inclusion of other stages is dependent on the key management strategy being implemented, as the TOE 
need not be involved in all of the key life-cycle (e.g. the TOE may only generate and distribute cryptographic 
keys). 

This family is intended to support the cryptographic key lifecycle and consequently defines requirements for 
the following activities: cryptographic key generation, cryptographic key distribution, cryptographic key access 
and cryptographic key destruction. This family should be included whenever there are functional requirements 
for the management of cryptographic keys. 

If Security audit data generation (FAU_GEN) Security Audit Data Generation is included in the PP/ST then, in 
the context of the events being audited: 

a) The object attributes may include the assigned user for the cryptographic key, the user role, the 
cryptographic operation that the cryptographic key is to be used for, the cryptographic key identifier and 
the cryptographic key validity period. 

b) The object value may include the values of cryptographic key(s) and parameters excluding any sensitive 
information (such as secret or private cryptographic keys). 

Typically, random numbers are used to generate cryptographic keys. If this is the case, then FCS_CKM.1 
Cryptographic key generation Cryptographic key generation should be used instead of the component 
FIA_S0S.2 TSF Generation of secrets TSF Generation of secrets. In cases where random number generation 
is required for purposes other than for the generation of cryptographic keys, the component FIA_S0S.2 TSF 
Generation of secrets TSF Generation of secrets should be used. 

E.1. 2 FCS_CKM.1 Cryptographic key generation 

E.1.2.1 User application notes 

This component requires the cryptographic key sizes and method used to generate cryptographic keys to be 
specified, this can be in accordance with an assigned standard. It should be used to specify the cryptographic 
key sizes and the method (e.g. algorithm) used to generate the cryptographic keys. Only one instance of the 
component is needed for the same method and multiple key sizes. The key size could be common or different 
for the various entities, and could be either the input to or the output from the method. 
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E.I. 2.2 Operations 
E.1. 2.2.1 Assignment 

In FCS_CKM.1 .1 , the PP/ST author should specify the cryptographic key generation algorithm to be used. 

In FCS_CKM.1.1, the PP/ST author should specify the cryptographic key sizes to be used. The key sizes 
specified should be appropriate for the algorithm and its intended use. 

In FCS_CKM.1.1, the PP/ST author should specify the assigned standard that documents the method used to 
generate cryptographic keys. The assigned standard may comprise none, one or more actual standards 
publications, for example, from international, national, industry or organisational standards. 

E.I .3 FCS_CKM.2 Cryptographic key distribution 

E.1 .3.1 User application notes 

This component requires the method used to distribute cryptographic keys to be specifred, this can be in 
accordance with an assigned standard. 

E.I .3.2 Operations 

E.1. 3.2.1 Assignment 

In FCS_CKM.2.1, the PP/ST author should specify the cryptographic key distribution method to be used. 

In FCS_CKM.2.1, the PP/ST author should specify the assigned standard that documents the method used to 
distribute cryptographic keys. The assigned standard may comprise none, one or more actual standards 
publications, for example, from international, national, industry or organisational standards. 

E.I .4 FCS_CKIW1.3 Cryptographic l<ey access 

E.I .4.1 User application notes 

This component requires the method used to access cryptographic keys be specified, this can be in 
accordance with an assigned standard. 

E.1 .4.2 Operations 

E.I. 4.2.1 Assignment 

In FCS_CKM.3.1, the PP/ST author should specify the type of cryptographic key access being used. 
Examples of types of cryptographic key access include (but are not limited to) cryptographic key backup, 
cryptographic key archival, cryptographic key escrow and cryptographic key recovery. 

In FCS_CKM.3.1, the PP/ST author should specify the cryptographic key access method to be used. 

In FCS_CKM.3.1, the PP/ST author sh^ould specify the assigned standard that documents the method used to 
access cryptographic keys. The assigned standard may comprise none, one or more actual standards 
publications, for example, from international, national, industry or organisational standards. 

t.1.5 FCS_CKM.4 Cryptographicl(ey destruction 
E.1 .5.1 User application notes 

This component requires the method used to destroy cryptographic keys be specified, this can be in 
accordance with an assigned standard. 
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E.I. 5.2 Operations 

E.1.5.2.1 Assignment 

In FCS_CKM.4.1, the PP/ST author should specify the key destruction method to be used to destroy 
cryptographic keys. 

In FCS_CKM.4.1, the PP/ST author should specify the assigned standard that documents the method used to 
destroy cryptographic keys. The assigned standard may comprise none, one or more actual standards 
publications, for example, from international, national, industry or organisational standards. 

E.2 Cryptographic operation (FCS_COP) 

E.2.1 User notes 

A cryptographic operation may have cryptographic mode(s) of operation associated with it. if this is the case, 
then the cryptographic mode(s) must be specified. Examples of cryptographrc modes of operation are cipher 
block chaining, output feedback mode, electronic code book mode, and cipher feedback mode. 

Cryptographic operations may be used to support one or more TOE security services. The Cryptographic 
operation {FCS_COP) component may need to be iterated more than once depending on: 

a) the user application for which the security service is being used. 

b) the use of different cryptographic algorithms and/or cryptographic key sizes. 

c) the type or sensitivity of the data being operated on. 

If Security audit data generation (FAU_GEN) Security audit data generation is included in the PP/ST then, in 
the context of the cryptographic operation events being audited: 

a) The types of cryptographic operation may include digital signature generation and/or verification, 
cryptographic checksum generation for integrity and/or for verification of checksum, secure hash 
(message digest) computation, data encryption and/or decryption, cryptographic key encryption and/or 
decryption, cryptographic key agreement and random number generation. 

b) The subject attributes may include subject role(s) and user(s) associated with the subject. 

c) The object attributes may include the assigned user for the cryptographic key, user role, cryptographic 
operation the cryptographic key is to be used for, cryptographic key identifier, and the cryptographic key 
validity period. 

E.2.2 FCS_C0P.1 Cryptographic operation 

E.2.2.1 User application notes 

This component requires the cryptographic algorithm and key size used to perform specified cryptographic 
operation(s) which can be based on an assigned standard. 

E.2.2.2 Operations 

E.2.2.2.1 Assignment 

In FCS_C0P.1.1. the PP/ST author should specify the cryptographic operations being performed. Typical 
cryptographic operations include digital signature generation and/or verification, cryptographic checksum 
generation for integrity and/or for verification of checksum, secure hash (message digest) computation, data 
encryption and/or decryption, cryptographic key encryption and/or decryption, cryptographic key agreement 
and random number generation. The cryptographic operation may be performed on user data or TSF data. 
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In FCS_C0P.1.1, the PP/ST author should specify the cryptographic algorithm to be used. Typical 
cryptographic algorithms include, but are not limited to, DES, RSA and IDEA. 

In FCS_C0P.1.1, the PP/ST author should specify the cryptographic key sizes to be used. The key sizes 
specified should be appropriate for the algorithm and its intended use. 

In FCS_C0P.1.1, the PP/ST author should specify the assigned standard that documents how the identified 
cryptographic operation(s) are performed. The assigned standard may comprise none, one or more actual 
standards publications, for example, from international, national, industry or organisational standards. 
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Annex F 

(normative) 

Class FDP: User data protection 



This class contains families specifying requirements for TOE security functions and TOE security function 
policies related to protecting user data. This class differs from FIA and FPT in that FDP: User data protection 
specifies components to protect user data, FIA specifies components to protect attributes associated with the 
user, and FPT specifies components to protect TSF information, 

The class does not contain explicit requirements for traditional Mandatory Access Controls (MAC) or 
traditional Discretionary Access Controls (DAC); however, such requirements may be constructed using 
components from this class. 

FDP: User data protection does not explicitly deal with confidentiality, integrity, or availability, as all three are 
most often intertwined in the policy and mechanisms. However, the TOE security policy must adequately 
cover these three objectives in the PP/ST. 

A final aspect of this class is that it specifies access control in terms of "operations". An operation is defined as 
a specific type of access on a specific object. It depends on the level of abstraction of the PP/ST author 
whether these operations are described as "read" and/or "write" operations, or as more complex operations 
such as "update the database". 

The access control policies are policies that control access to the information container. The attributes 
represent attributes of the container. Once the information is out of the container, the accessor is free to 
modify that information, including writing the information into a different container with different attributes. By 
contrast, an information flow policies controls access to the information, independent of the container. The 
attributes of the information, which may be associated with the attributes of the container (or may not, as in 
the case of a multi-level database) stay with the information as it moves. The accessor does not have the 
ability, in the absence of an explicit authorisation, to change the attributes of the information. 

This class is not meant to be a complete taxonomy of IT access policies, as others can be imagined. Those 
policies included here are simply those for which current experience with actual systems provides a basis for 
specifying requirements. There may be other forms of intent that are not captured in the definitions here. 

For example, one could imagine a goal of having user-imposed (and user-defined) controls on information 
flow (e.g. an automated implementation of the NO FOREIGN handling caveat). Such concepts could be 
handled as refinements of, or extensions to the FDP: User data protection components. 

Finally, it is important when looking at the components in FDP: User data protection to remember that these 
components are requirements for functions that may be implemented by a mechanism that also serves or 
could serve another purpose. For example, it is possible to build an access control policy (Access control 
policy (FDP_ACC)) that uses labels (FDPJFF.1 Simple security attributes) as the basis of the access control 
mechanism. 

A TOE security policy may encompass many security function policies (SFPs), each to be identified by the two 
policy oriented components Access control policy (FDP_ACC), and Information flow control policy (FDPJFC). 
These policies will typically take confidentiality, integrity, and availability aspects into consideration as required, 
to satisfy the TOE requirements. Care should be taken to ensure that all objects are covered by at least one 
SFP and that there are no conflicts arising from implementing the multiple SFPs. 

When building a PP/ST using components from the FDP: User data protection class, the following information 
provides guidance on where to look and what to select from the class. 

The requirements in the FDP: User data protection class are defined in terms of a security function 
(abbreviated SF) that will implement a SFP. Since a TOE may implement multiple SFPs simultaneously, the 
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PF VST author must specify the name for each SFP. so it can be referenced in other families. This name will 
the 'H be used In each component selected to indicate that it is being used as part of the definition of 
rec luirements for that function. This allows the author to easily indicate the scope for operations such as 
ob jects covered, operations covered, authorised users, etc. 

Ea ich instantiation of a component can apply to only one SFP. Therefore if an SFP is specified in a component 
tht 3n this SFP will apply to all the elements in this component. The components may be instantiated multiple 
tin nes within a PP/ST to account for different policies if so desired. 

T he key to selecting components from this family is to have a well defined TOE security policy to enable 

p roper selection of the components from the two policy components; Access control policy {FDP_ACC) and 

I nformation flow control policy (FDPJFC). In Access control policy (FDP_ACC) and Information flow control 

policy (FDPJFC) respectively, all access control policies and all information flow control policies are named. 

t-urthermore the scope of control of these components in terms of the subjects, objects and operations 

covered by this security function. The names of these policies are meant to be used throughout the remainder 

of the functional components that have an operation that calls for an assignment or selection of an "access 

control SFP" or an "information flow control SFP". The rules that define the functionality of the named access 

control and information flow control SFPs will be defined in the Access control functions (FDP_ACF) and 

Information flow control functions (FDPJFF) families (respectively). 

The following steps are guidance on how this class is applied in the construction of a PP/ST: 

a) Identify the policies to be enforced from the Access control policy (FDP_ACC). and Information flow 
control policy (FDPJFC) families. These families define scope of control for the policy, granulanty of 
control and may identify some rules to go with the policy. 

b) Identify the components and perform any applicable operations in the policy components The 
assignment operations may be performed generally (such as with a statement "All files") or specifically 
(»jhe files "A", "B", etc.) depending upon the level of detail known. 

c) Identify any applicable function components from the Access t:ontrol functions (FDP_ACF) and 
Information flow control functions (FDPJFF) families to address the named policy families from Access 
control policy (FDP_ACC) and Information flow control policy (FDPJFC). Perform the operations to make 
the components define the rules to be enforced by the named policies. This should make the components 
fit the requirements of the selected function envisioned or to be built. 

d) Identify who will have the ability to control and change security attributes under the function, such as only 
a security administrator, only the owner of the object, etc. Select the appropnate components from FMT: 
Security management and perform the operations. Refinements may be useful here to identify missing 
features, such as that some or all changes must be done via trusted path. 

e) Identify any appropriate components from the FMT: Security management for initial values for new 
objects and subjects. 

f) Identify any applicable rollback components from the Rollback (FDP_ROL) family. 

g) Identify any applicable residual information protection requirements from the Residual information 
protection (FDP_RIP) family. 

h) Identify any applicable import or export components, and how security attributes should be handled 
during import and export, from the Import from outside TSF control (FDP_ITC) and Export to outside TSF 
control (FDP_ETC) families. 

i) Identify any applicable internal TOE communication components from the Internal TOE transfer 
(FDPJTT) family. 

j) Identify any requirements for integrity protection of stored information from the Stored data integrity 
(FDP_SDI). 
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k) Identify any applicable inter-TSF communication components from the Inter-TSF user data confldentisjity 
transfer protection (FDP_UCT) or Inter-TSF user data integrity transfer protection (FDP_UIT) families. 

Figure F. 1 shows the decomposition of this class into its constituent components. 



FDPACX': Access coriliol policy 



FDP ACT: Access control Hinctioiis 



-FDP DAU: Data .iiitlieiitication 



FDP ETC: Export to outside TSF control 



FDP ffC: Inroniiation flow control policy 



FDP IFF: Irifoniialioii flow control runctions 



FDPITC: Inipoit from outside TSF control 



FDP ITT: Internal TOE transfer 



FDP_RIP: Residual information protection 



FDP ROL; Rollback 



FDP_SD1: Stored data integrity 



FDP_l)CT; Inter-TSF user data confidentiality transfer protection 



FDP^UIT: Intcr-TSF user data integrity transfer protection 




3 4 5 



Figure F.1 - FDP: User data protection class decomposition 
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F.I Access control policy (FDP_ACC) 

F.1.1 User notes 

This family is based upon the concept of arbitrary controls on the interaction of subjects and objects. The 
scope and purpose of the controls is based upon the attributes of the accessor (subject), the attributes of the 
container being accessed (object), the actions (operations) and any associated access control rules. 

The components in this family are capable of identifying the access control SFPs {by name) to be enforced by 
the traditional Discretionary Access Control (DAC) mechanisms. It further defines the subjects, objects and 
operations that are covered by identified access control SFPs. The rules that define the functionality of an 
access control SFP will be defined by other families, such as Access control functions (FDP_ACF) and 
Residual information protection (FDP_RIP). The names of the access control SFPs defined in Access control 
policy (FDP_ACC) are meant to be used throughout the remainder of the functional components that have an 
operation that calls for an assignment or selection of an "access control SFP." 

The access control SFP covers a set of triplets: subject, object, and operations. Therefore a subject can be 
covered by multiple access control SFPs but only with respect to a different operation or a different object. Of 
course the same applies to objects and operations. 

A critical aspect of an access control function that enforces an access control SFP is the ability for users to 
modify the attributes involved in access control decisions. The Access control policy (FDP_ACC) family does 
not address these aspects. Some of these requirements are left undefined, but can be added as refinements, 
while others are covered elsewhere in other families and classes such as FMT: Security management. 

There are no audit requirements in Access control policy (FDP_ACC) as this family specifies access control 
SFP requirements. Audit requirements will be found in families specifying functions to satisfy the access 
control SFPs identified in this family. 

This family provides a PP/ST author the capability to specify several policies, for example, a fixed access 
control SFP to be applied to one scope of control, and a flexible access control SFP to be defined for a 
different scope of control. To specify more than one access control policy, the components from this family 
can be iterated multiple times in a PP/ST to different subsets of operations and objects. This will 
accommodate TOEs that contain multiple policies, each addressing a particular set of operations and objects. 
In other words, the PP/ST author should specify the required information in the ACC compon^ent for each of 
the access control SFPs that the TSF will enforce. For example, a TOE incorporating three access control 
SFPs. each covering only a subset of the objects, subjects, and operations within the TOE, will contain one 
FDP_ACC.1 Subset access control component for each of the three access control SFPs, necessitating a 
total of three FDP_ACC.1 Subset access control components. 

F.1.2 FDP_ACC.1 Subset access control 

F.I. 2.1 User application notes 

The terms object and subject refer to generic elements in the TOE. For a policy to be implementable, the 
entities must be clearly identified. For a PP, the objects and operations might be expressed as types such as; 
named objects, data repositories, observe accesses, etc. For a specific system these generic terms (subject, 
object) must be refined, e.g. files, registers, ports, daemons, open calls, etc. 

This component specifies that the policy cover some weil-defined set of operations on some subset of the 
objects. It places no constraints on any operations outside the set - including operations on objects for which 
other operations are controlled. 

F.1.2.2 Operations 

F.1 .2.2.1 Assignment 

In FDP_ACC.1.1, the PP/ST author should specify a uniquely named access control SFP to be enforced by 
the TSF. 
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In FDP_ACC.1.1, the PP/ST author should specify the list of subjects, objects, and operations among subjects 
and objects covered by the SFP. 

F.I .3 FDP_ACC.2 Complete access control 

F.1.3.1 User application notes 

This component requires that all possible operations on objects, that are included in the SFP, are covered by 
an access control SFP. 

The PP/ST author must demonstrate that each combination of objects and subjects is covered by an access 
control SFP. 

F.1.3.2 Operations 

F.I. 3.2.1 Assignment 

In FDP_ACC.2.1, the PP/ST author should specify a uniquely named access control SFP to be enforced bv 
the TSF. ' 

In FDP_ACC.2.1, the PP/ST author should specify the list of subjects and objects covered by the SFP. All 
operations among those subjects and objects will be covered by the SFP. 

F.2 Access control functions (FDP_ACF) 

F.2.1 User notes 

This family describes the rules for the specific functions that can implement an access control policy named in 
Access control policy (FDP_ACC) which also specifies the scope of control of the policy. 

This family provides a PP/ST author the capability to describe the rules for access control. This results in a 
system where the access to objects will not change. An example of such an object is "Message of the Day", 
which is readable by all, and changeable only by the authorised administrator. This family also provides the 
PP/ST author with the ability to describe rules that provide for exceptions to the general access control rules. 
Such exceptions would either explicitly allow or deny authorisation to access an object. 

There are no explicit components to specify other possible functions such as two-person control, sequence 
rules for operations, or exclusion controls. However, these mechanisms, as well as traditional DAC 
mechanisms, can be represented with the existing components, by careful drafting of the access control mles. 

A variety of acceptable access control SFs may be specified in this family such as: 

• Access control lists (ACLs) 

• Time-based access control specifications 

• Origin-based access control specifications 

• Owner-controlled access control attributes 

F.2.2 FDP_ACF.1 Security attribute based access control 
F.2.2.1 User application notes 

This component provides requirements for a mechanism that mediates access control based on security 
attributes associated with subjects and objects. Each object and subject has a set of associated attributes, 
such as location, time of creation, access rights (e.g.. Access Control Lists (ACLs)). This component allows 
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the PP/ST author to specify the attributes that will be used for the access control mediation. This component 
allows access control rules, using these attributes, to be specified. 

Examples of the attributes that a PP/ST author might assign are presented in the following paragraphs. 

An identity attribute may be associated with users, subjects, or objects to be used for mediation. Examples of 
jsuch attributes might be the name of the program image used in the creation of the subject, or a security 
attribute assigned to the program image. 

A time attribute can be used to specify that access will be authorised during certain times of the day, during 
certain days of the week, or during a certain calendar year. 

A location attribute could specify whether the location is the location of the request for the operation, the 
location where the operation wilt be carried out, or both. It could be based upon internal tables to translate the 
logical interfaces of the TSF into locations such as through terminal locations, CPU locations, etc. 

A grouping attribute allows a single group of users to be associated with an operation for the purposes of 
access control. If required, the refinement operation should be used to specify the maximum number of 
definable groups, the maximum membership of a group, and the maximum number of groups to which a user 
can concurrently be associated. 

This component also provides requirements for the access control security functions to be able to explicitly 
authorise or deny access to an object based upon security attributes. This could be used to provide privilege, 
access rights, or access authorisations within the TOE. Such privileges, rights, or authorisations could apply to 
users, subjects (representing users or applications), and objects. 

F.2.2.2 Operations 

F.2.2.2.1 Assignment 

In FDP_ACF.1.1, the PP/ST author should specify an access control SFP name that the TSF is to enforce. 
The name of the access control SFP, and the scope of control for that policy are defined in components from 
Access control policy (FDP_ACC). 

In FDP_ACF.1.1, the PP/ST author should specify, for each controlled subject and object, the security 
attributes and/or named groups of security attributes that the function will use in the specification of the rules. 
For example, such attributes may be things such as the user identity, subject identity, role, time of day, 
location. ACLs, or any other attribute specified by the PP/ST author. Named groups of security attributes can 
be specified to provide a convenient means to refer to multiple security attributes. Named groups could 
provide a useful way to associate "roles" defined in Security management roles (FMT_SMR), and all of their 
relevant attributes, with subjects. In other words, each role could relate to a named group of attributes. 

In FDP_ACF.1.2, the PP/ST author should specify the SFP rules governing access among controlled subjects 
and controlled objects using controlled operations on controlled objects. These rules specify when access is 
granted or denied. It can specify general access control functions (e.g. typical permission bits) or granular 
access control functions (e.g. ACLs). 

In FDP_ACF.1.3, the PP/ST author should specify the rules, based on security attributes, that explicitly 
authorise access of subjects to objects that will be used to explicitly authorise access. These rules are in 
addition to those specified in FDP_ACF.1.1. They are included in FDP_ACF.1.3 as they are intended to 
contain exceptions to the rules in FDP_ACF.1.1. An example of rules to explicitly authorise access is based 
on a privilege vector associated with a subject that always grants access to objects covered by tKe access 
control SFP that has been specified. If such a capability is not desired, then the PP/ST author should specify 
"none". 

In FDP_ACF.1.4, the PP/ST author should specify the rules, based on security attributes, that explicitly deny 
access of subjects to objects. These rules are in addition to those specified in FDP_ACF.1.1. They are 
included in FDP_ACF.1.4 as they are intended to contain exceptions to the rules in FDP_ACf.1.1. An 
example of rules to explicitly deny access is based on a privilege vector associated with a subject that always 



151 



IS 14990 (Part 2) : 2006 
ISO/IEC 15408-2: 2005 

denies access to objects covered by the access control SFP that has been specified. If such a capability is not 
desired, then the PP/ST author should specify "none". 

F.3 Data authentication (FDP^DAU) 
F.3.1 Usernotes 

This family describes specific functions that can be used to authenticate "statLc" data. 

Components in this family are to be used when there is a requirement for "static" data authentication, i.e. 
where data is to be signed but not transmitted. (Note that the Non-repudiation of origin (FCO_NRO) family 
provides for non-repudiation of origin of information received during a data exchange.) 

F^.2 FDP_DAU.1 Basic Data Authentication 

F.3.2.1 User application notes 

This component may be satisfied by one-way hash functions (cryptographic checksum, fingerprint, message 
digest), to generate a hash value for a definitive document that may be used as verification of the validity or 
authenticity of its information content. 

F.3.2.2 Operations 

F.3.2.2.1 Assignment 

In FDP_DAU.1.1, the PP/ST author should specify the list of objects or information types for which the TSF 
shall be capable of generating data authentication evidence. 

In FDP_DAU.1.2, the PP/ST author should specify the list of subjects that will have the ability to verify data 
authentication evidence for the objects identified in the previous element. The list of subjects could be very 
specific, if the subjects are known, or it could be more generic and refer to a "type" of subject such as an 
identified role. 

F.3.3 FDP_DAU.2 Data Authentication with Identity of Guarantor 

F.3.3.1 User application notes 

This component additionally requires the ability to verify the identify of the user that provided the guarantee of 
authenticify (e.g. a trusted third parfy). 

F.3.3.2 Operations 

F.3.3.2.1 Assignment 

In FDP_DAU.2.1, the PP/ST author should specify the list of objects or information fypes for which the TSF 
shall be capable of generating data authentication evidence. 

In FDP_DAU.2.2, the PP/ST author should specify the list of subjects that will have the ability to verify data 
authentication evidence for the objects identified in the previous element as well as the identity of the user that 
created the data authentication evidence. 

F.4 Export to outside TSF control (FDP_ETC) 

F.4.1 Usernotes 

This family defines functions for exporting user data from the TOE such that its security attributes either can 
be explicitly preserved or can be ignored once it has been exported. Consistency of these security attributes 
are addressed by Inter-TSF TSF data consistency (FPT_TDC). 
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Export to outside TSF control (FDP_ETC) is concerned with limitations on export and association of security 
attributes with the exported user data. 

This family, and the corresponding Import family Import from outside TSF control (FDPJTC), address how the 
TOE deals with user data transferred into and outside its control. !n principle this family is concerned with the 
export of user data and its related security attributes. 

A variety of activities might be involved here: 

a) exporting of user data without any security attributes; 

b) exporting user data including security attributes where the two are associated with one another and the 
security attributes unambiguously represent the exported user data. 

If there are multiple SFPs (access control and/or information flow control) then it may be appropriate to iterate 
these components once for each named SFP. 

F.4.2 FDP_ETC.1 Export of user data without security attributes 

F.4.2.1 User application notes 

This component is used to specify the export of user data without the export of its security attributes. 

F.4.2.2 Operations 

F.4.2.2.1 Assignment 

In FDP_ETC.1.1, the PP/ST author should specify the access control SFP{s) and/or information flow control 
SFP(sj that will be enforced when exporting user data. The user data that this function exports is scoped lay 
the assignment of these SFPs. 

F.4.3 FDP_ETC.2 Export of user data witli security attributes 

F.4.3.1 User application notes 

The user data is exported together with its security attributes. The security attributes are unambiguously 
associated with the user data. There are several ways of achieving this association. One way that this can be 
achieved is by physically collocating the user data and the security attributes (e.g. the same floppy), or by 
using cryptographic techniques such as secure signatures to associate the attributes and the user data. Inter- 
TSF trusted channel (FTPJTC) could be used to assure that the attributes are correctly received at the other 
trusted IT product while Inter-TSF TSF data consistency (FPT_TDC) can be used to make sure that those 
attributes are properly interpreted. Furthermore, Trusted path (FTP_TRP) could be used to make sure that the 
export is being initiated by the proper user. 

F.4.3.2 Operations 

F.4.3.2.1 Assignment 

In FDP_ETC.2.1, the PP/ST author should specify the access control SFP(s) and/or information flow control 
SFP(s) that will be enforced when exporting user data. The user data that this function exports is scoped by 
the assignment of these SFPs. 

In FDP_ETC.2.4, the PP/ST author should specify any additional exportation control rules or "none" if there 
are no additional exportation control rules. These rules will be enforced by the TSF in addition to the access 
control SFPs and/or information flow control SFPs selected in FDP ETC.2.1 . 
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F.5 Information flow control policy (FDPJFC) 

F.5.1 User notes 

This family covers the identification of information flow control SFPs; and, for each, specifies the scope of 
control of the SFP. 

Examples of security policies that might satisfy this objective are: 

• Bell and La Padula Security model [1]; 

• Biba Integrity model [2]; 

• Non-interference [5], [6]. 

The components in this family are capable of identifying the information flow control SFPs to be enforced by 
the traditional Mandatory Access Control mechanisms that would be found in a TOE. However, they go 
beyond just the traditional MAC mechanisms and can be used to identify and describe non-interference 
policies and state-transitions. It further defines the subjects under control of the policy, the information under 
control of the policy, and operations which cause controlled information to flow to and from controlled subjects 
for each information flow control SFP in the TOE. The functionality that defines the rules of an information flow 
control SFP will be defined by other families such as Information flow control functions (FDP_IFF) and 
Residual information protection {FDP_RIP). The information flow control SFPs named here in Information flow 
control policy (FDP_IFC) are meant to be used throughout the remainder of the functional components that 
have an operation that calls for an assignment or selection of an "information flow control SFP." 

These components are quite flexible. They allow the domain of flow control to be specified and there is no 
requirement that the mechanism be based upon labels. The different elements of the information flow control 
components also permit different degrees of exception to the policy. 

Each SFP covers a set of triplets: subject, information, and operations that cause information to flow to and 
from subjects. Some information flow control policies may be at a very low level of detail and explicitly 
describe subjects in terms of processes within an operating system. Other information flow control policies 
may be at a high level and describe subjects in the generic sense of users or input/output channels. If the 
information flow control policy is at too high a level of detail, it may not clearly define the desired IT security 
functions. In such cases, it is more appropriate to include such descriptions of information flow control policies 
as objectives. Then the desired IT security functions can be specified as supportive of those objectives. 

In the second component {FDP_IFC.2 Complete information flow control), each information flow control SFP 
will cover all possible operations that cause information covered by that SFP to flow to and from subjects 
covered by that SFP. Furthermore, all information flows will need to be covered by a SFP. Therefore for each 
action that causes information to flow, there will be a set of rules that define whether the action is allowed. If 
there are multiple SFPs that are applicable for a given information flow, all involved SFPs must allow this flow 
before it is permitted to take place. 

An information flow control SFP covers a well-defined set of operations. The SFPs coverage may be 
"complete" with respect to some information flows, or it may address only some of the operations that affect 
the information flow. 

An access control SFP controls access to the objects that contain Information. An information flow control SFP 
controls access to the Information, independent of its container. The attributes of the information, which may 
be associated with the attributes of the container (or may not, as in the case of a multi-level database) stay 
with the information as it flows. The accessor does not have the ability, in the absence of an explicit 
authorisation, to change the attributes of the information. 

Information flows and operations can be expressed at multiple levels. In the case of a ST, the information 
flows and operations might be specified at a system-specific level: TCP/IP packets flowing through a firewall 
based upon known IP addresses. For a PP, the information flows and operations might be expressed as 
types: email, data repositories, observe accesses, etc. 
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The components in this family can be applied multiple times in a PP/ST to different subsets of operations and 
objects. This will accommodate TOEs that contain multiple policies, each addressing a particular set of objects, 
subjects, and operations. 

F.5.2 FDPJFd Subset information flow control 

F.5.2.1 User application notes 

This component requires that an information flow control policy apply to a subset of the possible operations in 
the TOE, 

F.5.2.2 Operations 

F.5.2.2.1 Assignment 

In FDPJFd. 1, the PP/ST author should specify a uniquely named information flow control SFP to be 
enforced by the TSF. 

In FOPJFC.1.1, the PP/ST author should specify the list of subjects, Infomnation, and operations which cause 
controlled information to flow to and from controlled subjects covered by the SFP. As mentioned above, 1he 
list of subjects could be at various levels of detail depending on the needs of the PP/ST author. It could 
specify users, machines, or processes for example. Information could refer to data such as email or network 
protocols, or more specific objects similar to those specified under an access control policy. If the information 
that is specified is contained within an object that is subject to an access control policy, then both the access 
control policy and information flow control policy must be enforced before the specified information could flow 
to or from the object. 

F.5.3 FDP_IFC.2 Complete information flow control 

F.5.3.1 User application notes 

This component requires that all possible operations that cause information to flow to and from subjects 
included in the SFP. are covered by an information flow control SFP. 

The PP/ST author must demonstrate that each combination of information flows and subjects is covered by an 
informatfon flow control SFP. 

F.5.3.2 Operations 

F.5.3.2.1 Assignment 

In FDP_IFC.2.1, the PP/ST author should specify a uniquely named information flow control SFP to be 
enforced by the TSF. 

In FDP_IFC.2.1, the PP/ST author should specify the list of subjects and infomiation that will be covered by 
the SFP. All operations that cause that information to flow to and from subjects will be covered by the SFP. As 
mentioned above, the list of subjects could be at various levels of detail depending on the needs of the PP/ST 
author. It could specify users, machines, or processes for example. Information could refer to data such as 
email or network protocols, or more specific objects similar to those specified under an access control policy. 
If the information that is specified is contained within an object that is subject to an access control policy, then 
both the access control policy and information flow control policy must be enforced before the specified 
information could flow to or from the object. 

F.6 Information flow control functions (FDPJFF) 

F.6.1 Usernotes 

This family describes the rules for the specific functions that can implement the information flow control SFPs 
named in Information flow control policy (FDPJFC), which also specifies the scope of control of the policies. It 
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consists of two "trees:" one addressing the common information flow control function issues, and a second 
addressing illicit information flows (i.e. covert channels) with respect to one or more information flow control 
SFPs. This division arises because the issues concerning illicit information flows are, in some sense, 
orthogonal to the rest of an SFP. Illicit information flows are flows In violation of policy; thus they are not a 
policy issue. 

In order to implement strong protection against disclosure or modification in the face of untrusted software, 
controls on information flow are required. Access controls alone are not sufficient because they only control 
access to containers, allowing the information they contain to flow, without controls, throughout a system. 

In this family, the phrase "types of illicit information flows" is used. This phrase may be used to refer to the 
categorisation of flows as "Storage Channels" or "Timing Channels", or it can refer to improved categorisations 
reflective of the needs of a PP/ST author. 

The flexibility of these components allows the definition of a privilege policy within FDPJFF.I Simple security 
attributes and FDPJFF.2 Hierarchical security attributes to allow the controlled bypass of all or part of a 
particular SFP. If there is a need for a predefined approach to SFP bypass, the PP/ST author should consider 
incorporating a privilege policy. 

F.6.2 FDPJFF.I Simple security attributes 

F.6.2.1 User application notes 

This component requires security attributes on information, and on subjects that cause that information to flow 
and subjects that act as recipients of that information. The attributes of the containers of the information 
should also be considered if it is desired that they should play a part in information flow control decisions or if 
they are covered by an access control policy. This component specifies the key rules that are enforced, and 
describes how security attributes are derived. For example, this component should be used when at least one 
of the information flow control SFPs in the TSP is based on labels as defined in the Bell and LaPadula security 
policy modelfl], but these security attributes do not form a hierarchy. 

This component does not specify the details of how a security attribute is assigned (i.e. user versus process). 
Flexibility in policy is provided by having assignments that allow specification of additional policy and function 
requirements, as necessary. 

This component also provides requirements for the information flow control functions to be able to explicitly 
authorise and deny an information flow based upon security attributes. This could be used to implement a 
privilege policy that covers exceptions to the basic policy defined in this component. 

F.6.2.2 Operations 

F.6.2.2.1 Assignment 

In FDPJFF.1.1, the PP/ST author should specify the information flow control SFPs enforced by the TSF. The 
name of the information flow control SFP, and the scope of control for that policy are defined in components 
from Information flow control policy (FDPJFC). 

In FDPJFF.1.1, the PP/ST author should specify, for each type of controlled subject and information, the 
security attributes that are relevant to the specification of the SFP rules. For example, such security attributes 
may be things such the subject identifier, subject sensitivity label, subject clearance label, information 
sensitivity label, etc. The types of security attributes should be sufficient to support the environmental needs. 

In FDPJFF.I. 2, the PP/ST author should specify for each operation, the security attribute-based relationship 
that must hold between subject and information security attributes that the TSF will enforce. 

In FDP_IFF.1.3, the PP/ST author should s pecify any additional information flow control SFP rules that the 
TSF is to enforce. If there are no additional rules then the PP/ST author should specify "none". 
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In f^DP_IFF.1.4, the PP/ST author should specify any additional SFP capabilities that the TSF Is to provide. If 
there are no additional capabilities then the PP/ST author should specify "none". 

In FDP_IFF.1.5, the PP/ST author should specify the rules, based on security attributes, that explicitly 
authorise information flows. These rules are in addition to those specified in the preceding elements. They are 
included in FDP_IFF.1.5 as they are intended to contain exceptions to the rules in the preceding elements. An 
example of rules to explicitly authorise information flows is based on a privilege vector associated with a 
subject that always grants the subject the ability to cause an information flow for information that is covered by 
the SFP that has been specified. If such a capability is not desired, then the PP/ST author should specify 
"none". 

In FDP_IFF.1.6, the PP/ST author should specify the rules, based on security attributes, that explicitly deny 
information flows. These rules are in addition to those specified in the preceding elements. They are included 
in FDP_IFF.1.6 as they are intended to contain exceptions to the rules in the preceding elements. An example 
of rules to explicitly authorise information flows is based on a privilege vector associated with a subject that 
always denies the subject the ability to cause an Information flow for information that is covered by the SFP 
that has been specified. If such a capability is not desired, then the PP/ST author should specify "none". 

F.6.3 FDPJFF.2 Hierarchical security attributes 

F.6.3.1 User application notes 

This component requires that all information flow control SFPs in the TSP use hierarchical security attributes 
that form a lattice. 

For example, it should be used when at least one of the information flow control SFPs in the TSP is based on 
labels as defined in the Bell and LaPadula security policy model [1] and form a hierarchy. 

It is important to note that the hierarchical relationship requirements identified in FDP_IFF.2.5 need only apply 
to the information flow control security attributes for the information flow control SFPs that have been identified 
in FDPJFF.2. 1. This component is not meant to apply to other SFPs such as access control SFPs. 

Like the preceding component, this component could also be used to implement a privilege policy that covers 
rules that allow for the explicit authorisation or denial of Information flows. 

If it is the case that multiple information flow control SFPs are to be specified, and that each of these SFPs will 
have their own securify attributes that are not related to one another, then the PP/ST author should iterate this 
component once for each of those SFPs. Othenwise a conflict might arise with the sub-items of FDPJFF.2. 5 
since the required relationships will not exist. 

F.6.3.2 Operations 

F.6.3.2.1 Assignment 

In FDPJFF.2. 1, the PP/ST author should specify the information flow control SFPs enforced by the TSF. The 
name of the information flow control SFP, and the scope of control for that policy are defined in components 
from Information flow control policy (FDPJFC). 

In FDPJFF.2. 1, the PP/ST author should specify, for each type of controlled subject and information, the 
security attributes that are relevant to the specification of the SFP rules. For example, such security attributes 
may be things such the subject identifier, subject sensitivity label, subject clearance label, information 
sensitivity label, etc. The types of security attributes should be sufficient to support the environmental needs. 

In FDP_IFF.2.2, the PP/ST author should specify for each operation, the security attribute-based relationship 
that must hold between subject and information security attributes that the TSF will enforce. These 
relationships should be based upon the ordering relationships between the security attributes. 

In FDPJFF.2.3, the PP/ST author should specify any additional information flow control SFP rules that the 
TSF is to enforce. If there are no additional rules then the PP/ST author should specify "none". 
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In FDPJFF.2.4, the PP/ST author should specify any additional SFP capabilities that the TSF is to enforce. If 
there are no additional rules then the PP/ST author should specify "none". 

In FDP_IFF.2.5, the PP/ST author should specify the rules, based on security attributes, that explicitly 
authorise information flows. These rules are in addition to those specified in the preceding elements. They are 
included in FDPJFF.2.5 as they are intended to contain exceptions to the rules in the preceding elements. An 
example of rules to explicitly authorise information flows is based on a privilege vector associated with a 
subject that always grants the subject the ability to cause an informationilow for information that is covered by 
the SFP that has been specified. If such a capability is not desired, then the PP/ST author should specify 
"none". 

In FDP_IFF.2.6, the PP/ST author should specify the rules, based on security attributes, that explicitly deny 
information flows. These rules are in addition to those specified in the preceding elements. They are included 
in FDPJFF.2.6 as they are intended to contain exceptions to the rules in the preceding elements. An example 
of rules to explicitly authorise information flows is based on a privilege vector associated with a subject that 
always denies the subject the ability to cause an information flow for information that is covered by the SFP 
that has been specified. If such a capability is not desired, then the PP/ST author should specify "none". 

F.6,4 FDP_IFF.3 Limited illicit information flows 

F.6.4.1 User application notes 

This component should be used when at least one of the SFPs that requires control of illicit information flows 
does not require elimination of flows. 

For the specified illicit information flows, certain maximum capacities should be provided. In addition a PP/ST 
author has the ability to specify whether the illicit information flows must be audited. 

F.6.4.2 Operations 

F.6.4.2.1 Assignment 

In FDP_IFF.3.1, the PP/ST author should specify the information flow control SFPs enforced by the TSF. The 
name of the information flow control SFP, and the scope of control for that policy are defined in components 
from Information flow control policy (FDPJFC). 

In FDP_IFF.3.1, the PP/ST author should specify the types of illicit information flows that are subject to a 
maximum capacity limitation. 

In FDPJFF.3.1, the PP/ST author should specify the maximum capacity permitted for any identified Illicit 
information flows. 

F.6.5 FDP_IFF.4 Partial elimination of illicit information flows 

F.6.5.1 User application notes 

This component should be used when all the SFPs that requires control of illicit information flows require 
elimination of some (but not necessarily all) illicit information flows. 

F.6.5.2 Operations 

F.6.5.2.1 Assignment 

In FDPJFF.4.1, the PP/ST author should specify the information flow control SFPs enforced by the TSF. The 
name of the information flow control SFP, and the scope of control for that policy are defined in components 
from Information flow control policy (FDP_1FC), 

In FDPJFF.4.1, the PP/ST author should specify the types of illicit information flows which are subject to a 
maximum capacity limitation. 



158 



IS 14990 (Part 2): 2006 
ISO/IEC 15408-2 -.2005 

In FDPJFF.4.1, the PP/ST author should specify the maximum capacity permitted for any identified illicit 
information flows. 

In FDPJFF.4.2, the PP/ST author should specify the types of illicit information flows to be eliminated. This list 
may not be empty as this component requires that some illicit information flows are to be eliminated. 

F.6.6 FDPJFF.5 No illicit information flows 

F.6.6.1 User application notes 

This component should be used when the SFPs that require control of illicit information flows require 
elimination of all illicit information flows. However, the PP/ST author should carefully consider the potential 
impact that eliminating all illicit information flows might have on the normal functional operation of the TOE. 
Many practical applications have shown that there is an indirect relationship between illicit information flows 
and normal functionality within a TOE and eliminating all illicit information flows may result in less than desired 
functionality. 

F.6.6,2 Operations 

F.6.6.2.1 Assignment 

In FDPJFF.5.1, the PP/ST author should specify the information flow control SFP for which illicit information 
flows are to be eliminated. The name of the information flow control SFP, and the scope of control for that 
policy are defined in components from Information flow control policy (FDP_IFC). 

F.6.7 FDP JFF.6 Illicit information flow monitoring 

F.6.7.1 User application notes 

This component should be used when it is desired that the TSF provide the ability to monitor the use of illicit 
information flows that exceed a specified capacity. If it is desired that such flows be audited, then this 
component could serve as the source of audit events to be used by components from the Security audit data 
generation (FAU_GEN) family. 

F.6.7.2 Operations 

F.6.7.2.1 Assignment 

In FDPJFF.6.1, the PP/ST author should specify the information flow control SFPs enforced by the TSF. The 
name of the information flow control SFP, and the scope of control for that policy are defined in components 
from Information flow control policy (FDP_1FC). 

In FDP_IFF.6.1, the PP/ST author should specify the types of illicit information flows that will be monitored for 
exceeding a maximum capacity. 

In FDPJFF.6.1, the PP/ST author should specify the maximum capacity above which illicit information flows 
will be monitored by the TSF. 

F.7 Import from outside TSF control (FDPJTC) 

F.7.1 Usernotes 

This family defines mechanisms for importing user data from outside the TSC into the TOE such that the user 
data security attributes can be preserved. Consistency of these security attributes are addressed by Inter-TSF 
TSF data consistency (FPT_TDC). 

Import from outside TSF control (FDPJTC) is concerned with limitations on import, user specification of 
security attributes, and association of security attributes with the user data. 
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This family, and the corresponding export family Export to outside TSF control (FDP_ETG), address how the 
TOE deals with user data outside its control. This family is concerned with assigning and abstraction of the 
user data security attributes. 

A variety of activities might be involved here: 

a) importing user data from an unformatted medium (e.g. floppy disk, tape, scanner, video or audit signal), 
without including any security attributes, and physically marking the medium to indicate its contents; 

b) importing user data, including security attributes, from a medium and verifying that the object security 
attributes are appropriate; 

c) importing user data, including security attributes, from a medium using a cryptographic sealing technique 
to protect the association of user data and security attributes. 

This family is not concerned with the determination of whether the user data may be imported. It is concerned 
with the values of the security attributes to associate with the imported user data. 

There are two possibilities for the import of user data: either the user data is unambiguously associated with 
reliable object security attributes (values and meaning of the security attributes is not modified), or no reliable 
security attributes (or no security attributes at all) are available from the import source. This family addresses 
both cases. 

If there are reliable security attributes available, they may have been associated with the user data by physical 
means (the security attributes are on the same media), or by logical means (the security attributes are 
distributed differently, but include unique object identification, e.g. cryptographic checksum). 

This family is concerned with importing user data and maintaining the association of security attributes as 
required by the SFP. Other families are concerned with other import aspects such as consistency, trusted 
channels, and integrity that are beyond the scope of this family. Furthermore, Import from outside TSF control 
(FDP_ITC) is only concerned with the interface to the import medium. Export to outside TSF control 
(FDP_ETC) is responsible for the other end point of the medium (the source). 

Some of the well known import requirements are: 

a) importing of user data without any security attributes; 

b) importing of user data including security attributes where the two are associated with one another and the 
security attributes unambiguously represent the information being imported. 

These import requirements may be handled by the TSF with or without human intervention, depending on the 
IT limitations and the organisational security policy. For example, if user data is received on a "confidential" 
channel, the security attributes of the objects will be set to "confidential". 

If there are multiple SFPs (access control and/or information flow control) then it may be appropriate to iterate 
these components once for each named SFP. 

F.7.2 FDPJTd Import of user data without security attributes 

F.7.2.1 User application notes 

This component is used to specify the import of user data that does not have reliable (or any) security 
attributes associated with it. This function requires that the security attributes for the imported user data be 
initialised within the TSF. It could also be the case that the PP/ST author specifies the rules for import. It may 
be appropriate, in some environments, to require that these attributes be supplied via a trusted path or a 
trusted channel mechanism. 
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F.7.2.2 Operations 
F.7.2.2.1 Assignment 

In FDPJTC.1.1, the PP/ST author should specify the access control SFP(s) and/or Information flow control 
SFP(s) that will be enforced when importing user data from outside of the TSC. The user data that this 
function imports is scoped by the assignment of these SFPs. 

In FDPJTC.1 .3. the PP/ST author should specify any additional importation control rules or "none" if there are 
no additional importation corrtrol rules. These rules will be enforced by the TSF in addition to the access 
control SFPs and/or information flow control SFPs selected in FDPJTd .1 . 

F.7.3 FDPJTC.2 Import of user data with security attributes 
F.7.3.1 User application notes 

This component is used to specify the import of user data that has reliable security attributes associated with it. 
This function relies upon the security attributes that are accurately and unambiguously associated with the 
objects on the import medium. Once imported, those objects will have those same attributes. This requires 
Inter-TSF TSF data consistency (FPT_TDC) to ensure the consistency of the data. It could also be the case 
that the PP/ST author specifies the rules for import. 

F.7.3.2 Operations 

F.7.3.2.1 Assignment 

In FDPJTC.2. 1, the PP/ST author should specify the access control SFP and/or infomiation flow control SFP 
that will be enforced when importing user data from outside of the TSC. The user data that this function 
imports is scoped by the assignment of these SFPs. 

In FDPJTC.2.5, the PP/ST author should specify any additional importation control rules or "none" if there are 
no additional importation control rules. These rules will be enforced by the TSF in addition to the access 
control SFPs and/or information flow control SFPs selected in FDP_ITC.2.1. 

F.8 Internal TOE transfer (FDPJTT) 

F.8.1 Usernotes 

This family provides requirements that address protection of user data when it is transferred between parts of 
a TOE across an internal channel. This may be contrasted with the Inter-TSF user data confidentiality transfer 
protection {FDP_UCT) and Inter-TSF user data integrity transfer protection (FDP_UIT) family, which provide 
protection for user data when it is transferred between distinct TSFs across an external channel, and Export to 
outside TSF control (FDP_ETC) and Import from outside TSF control (FDP ITC), which address transfer of 
data to or from outside the TSF's Control. 

The requirements in this family allow a PP/ST author to specify the desired security for user data while in 
transit within the TOE. This security could be protection against disclosure, modification, or loss of availability. 

The determination of the degree of physical separation above which this family should apply depends on the 
intended environment of use. In a hostile environment, there may be risks arising from transfers between parts 
of the TOE separated by only a system bus. In more benign environments, the transfers may be across more 
traditional networit media. 

If there are multiple SFPs (access control and/or information flow control) then it may be appropriate to iterate 
these components once for each named SFP. 
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F.8.2 FDPJTT.1 Basic internal transfer protection 

F.8.2.1 Operations 

F.8.2.1.1 Assignment 

In FDPJTT.1. 1, the PP/ST author should specify the access control SFP(s) and/or information flow control 
SFP(s) covering the information being transferred. 

F.8.2.1. 2 Selection 

In FDPJTT.1 .1 . the PP/ST author should specify the types of transmission errors that the TSF should prevent 
occuring for user data while in transport. The options are disclosure, modification, loss of use. 

F.8.3 FDPJTT.2 Transmission separation by attribute 

F.8.3.1 User application notes 

This component could, for example, be used to provide different forms of protection to information with 
different clearance levels. 

One of the ways to achieve separation of data when it is transmitted is through the use of separate logical or 
physical channels. 

F.8.3.2 Operations 

F.8.3.2.1 Assignment 

In FDPJTT.2.1, the PP/ST author should specify the access control SFP(s) and/or information flow control 
SFP{s) covering the information being transferred. 

F.8.3.2.2 Selection 

In FDP_ITT.2.1 . the PP/ST author should specify the types of transmission errors that the TSF should prevent 
occuring for user data while in transport. The options are disclosure, modification, loss of use. 

F.8.3.2.3 Assignment 

In FDP_ITT.2.2, the PP/ST author should specify the security attributes, the values of which the TSF will use 
to determine when to separate data that is being trasmitted between physically-separated parts of the TOE. 
An example is that user data associated with the identity of one owner is transmitted separately from the user 
data associated with the identify of a different owner. In this case, the value of the identity of the owner of the 
data is what is used to determine when to separate the data for transmission. 

F.8.4 FDP_nT.3 Integrity monitoring 

F.8.4.1 User application notes 

This component is used in combination with either FDP_ITT.1 Basic internal transfer protection or FDPJTT.2 
Transmission separation by attribute. It ensures that the TSF checks received user data (and their attributes) 
for integrity. FDPJTT.1 Basic internal transfer protection or FDPJTT.2 Transmission separation by attribute 
will provide the data in a manner such that it is protected from modification (so that FDPJTT.3 Integrity 
monitoring can detect any modifrcations). 

The PP/ST author has to specify the types of errors that must be detected. The PP/ST author should consider: 
modification of data, substitution of data, unrecoverable ordering change of data, replay of data, incomplete 
data, in addition to other integrity errors. 
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The PP/ST author must specify the actions that the TSF should take on detection of a failure. For example: 
ignore the user data, request the data again, inform the authorised administrator, reroute traffic for other tines. 

F.8.4.2 Operations 

F.8.4.2.1 Assignment 

In FDPJTT.3.1, the PP/ST author should specify the access control SFP(s) and/or information flow control 
SFP(s) covering the information being transferred and monitored for integrity errors. 

In FDPJTT.3.1, the PP/ST author should specify the type of possible integrity errors to be monitored during 
transmission of the user data. 

fn FDPJTT.3.2, the PP/ST author should specify the action to be taken by the TSF when an integrity error is 
encountered. An example might be that the TSF should request the resubmission of the user data. The 
SFP(s) specified in FDPJTT.3.1 will be enforced as the actions are taken by the TSF, 

F.8.5 FDPJTT.4 Attribute-based integrity monitoring 

F.8.5.1 User application notes 

This component is used in combination with^DPJTT.2 Transmission separation by attribute. It ensures that 
the TSF checks received user data, that has been transmitted by separate channels (based on values of 
specified security attributes), for integrity. It allows the PP/ST author to specify actions to be taken upon 
detection of an integrity error. 

For example, this component could be used to provide different integrity error detection and action for 
information at different integrity levels. 

The PP/ST author has to specify the types of errors that must be detected. The PP/ST author should consider: 
modification of data, substitution of data, unrecoverable ordering change of data, replay of data, incomplete 
data, in addition to other integrity errors. 

The PP/ST author should specify the attributes (and associated transmission channels) that necessitate 
integrity error monitoring 

The PP/ST author must specify the actions that the TSF should take on detection of a failure. For example: 
ignore the user data, request the data again, inform the authorised administrator, reroute traffic for other lines. 

F.8.5.2 Operations 

F.8.5.2.1 Assignment 

In FDPJTT.4.1, the PP/ST author should specify the access control SFP(s) and/or information flow control 
SFP(s) covering the information being transferred and monitored for integrity errors. 

In FDP_ITT.4.1, the PP/ST author should specify the type of possible integrity errors to be monitored during^ 
transmission of the user data. 

In FDPJTT.4.1 , the PP/ST author should specify a list of security attributes that require separate transmission 
channels. This list is used to determine which user data to monitor for integrity errors., based on its security 
attributes and its transmission channel. This element is directly related to FDPJTT.2 Transmission separation 
by attribute. 

In FDPJTT.4.2, the PP/ST author should specify the action to be taken by the TSF when an integrity error is 
encountered. An example might be that the TSF should request the resubmission of the user data. The 
SFP(s) specified in FDPJTT.3.1 will be enforced as the actions are taken by the TSF. 
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F.9 Residual information protection (FDP_RIP) 
F.9.1 Usernotes 

This family addresses the need to ensure that deleted information is no longer accessible, and that newly- 
created objects do not contain information from previously used objects within the TOE. This family does not 
address objects stored off-line. 

This family requires protection for information that has been logically deleted or released (not available to the 
user but still within the system and may be recoverable). In particular, this includes information that is 
contained in an object, as part of the TSF reusable resources, where destruction of the object does not 
necessarily equate to destruction of the resource or any contents of the resource. 

It also applies to resources that are serially reused by different subjects within the system. For example, most 
operating systems typically rely upon hardware registers (resources) to support processes within the system. 
As processes are swapped from a "run" state to a "sleep" state (and vice versa), these registers are serially 
reused by different subjects. While this "swapping" action may not be considered an allocation or deallocation 
of a resource. Residual information protection (FDP_RIP) could apply to such events and resources. 

Residual information protection (FDP_RIP) typically controls access to information that Is not part of any 
currently defined or accessible object; however, in certain cases this may not be true. For example, object "A" 
is a file and object "B" is the disk upon which that file resides. If object "A" is deleted, the information from 
object "A" is under the control of Residual information protection (FDP_RIP) even though It is still part of object 

"B". 

It is important to note that Residual information protection (FDP_R1P) applies only to on-line objects and not 
off-line objects such as those backed-up on tapes. For example, if a file is deleted in the TOE, Residual 
information protection (FDP_RIP) can be instantiated to require that no residual information exists upon 
deallocation; however, the TSF cannot extend this enforcement to that same file that exists on the off-line 
back-up. Therefore that same file is still available. If this is a concern, then the PP/ST author should make 
sure that the proper environmental objectives are in place to support administrative guidance to address off- 
line objects. 

Residual information protection (FDP_R1P) and Rollback (FDP_ROL) can conflict when Residual information 
protection (FDP_RIP) is instantiated to require that residual information be cleared at the time the application 
releases the object to the TSF (i.e. upon deallocation). Therefore, the Residual information protection 
(FDP_RIP) selection of "deallocation" should not be used with Rollback (FDP_ROL) since there would be no 
information to roll back. The other selection, "unavailability upon allocation", may be used with Rollback 
(FDP_ROL), but there is the risk that the resource which held the Information has been allocated to a new 
object before the roll back took place. If that were to occur, then the roll back would not be possible. 

There are no audit requirements in Residual information protection (FDP_RIP) because this is not a user- 
invokable function. Auditing of allocated or deallocated resources would be auditable as part of the access 
control SFP or the information flow control SFP operations. 

This family should apply to the objects specified in the access control SFP(s) or the infomnation flow control 
SFP(s) as specified by the PP/ST author. 

F.9.2 FDP_RIP.1 Subset residual information protection 

F.9.2.1 User application notes 

This component requires that, for a subset of the objects In the TOE, the TSF will ensure that there is no 
available residual Information contained in a resource allocated to those objects or deallocated from those 
objects. 
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F.9.2.2 Operations 

F.9.2.2.1 Selection 

In FDP_RIP.1 .1 , the PP/ST author should specify the event, allocation of the resource to or deallocation of the 
resource from, that invokes the residual information protection function. 

F.9.2.2.2 Assignment 

In FDP_RIP.1 .1 , the PP/ST author should specify the list of objects subject to residual information protection. 

F.9.3 FDP_RIP.2 Full residual information protection 

F.9.3.1 User application notes 

This component requires that for all objects in the TOE. the TSF will ensure that there is no available residual 
information contained in a resource allocated to those objects or deallocated from those objects. 

F.9.3.2 Operations 

F.9.3.2.1 Selection 

In FDP_RIP.2.1, the PP/ST author should specify the event, allocation of the resource to or deallocation of the 
resource from, that invokes the residual information protection function. 

F.10 Rollback (FDP_ROL) 

F.10.1 User notes 

This family addresses the need to return to a well defined valid state, such as the need of a user to undo 
modifications to a file or to undo transactions in case of an incomplete series of transaction as in the case of 
databases. 

This family is intended to assist a user in returning to a well defined valid state after the user undoes the last 
set of actions, or, in distributed databases, the return of all of the distributed copies of the databases to the 
state before an operation failed. 

Residual information protection (FDP_RIP) and Rollback (FDP_ROL) conflict when Residual information 
protection (FDP_RIP) enforces that the contents will be made unavailable at the time that a resource is 
deallocated from an object. Therefore, this use of Residual information protection (FDP_RIP) cannot be 
combined with Rollback (FDP_ROL) as there would be no information to roll back. Residual information 
protection (FDP_RIP) can be used only with Rollback (FDP_ROL) when it enforces that the contents will be 
unavailable at the time that a resource is allocated to an object. This is because the Rollback (FDP_ROL) 
mechanism will have an opportunity to access the previous information that may still be present In the TOE in 
order to successfully roll back the operation. 

The rollback requirement is bounded by certain limits. For example a text editor typically only allows you roll 
back up to a certain number of commands. Another example would be backups. If backup tapes are rotated, 
after a tape is reused, the information can no longer be retrieved. This also poses a bound on the rollback 
requirement. 

F.I 0.2 FDP„ROL.1 Basic rollback 

F.10.2.1 User application notes 

This component allows a user or subject to undo a set of operations on a predefined set of objects. The undo 
is only possible within certain limits, for example up to a number of characters or up to a time limit. 
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F.10.2.2 Operations 

F.I 0.2.2.1 Assignment 

In FDP_R0L,1.1, the PP/ST author should specify the access control SFP(s) and/or information flow control 
SFP(s) that will be enforced when performing roHback operations. This is necessary to make sure that roll 
back is not used to circumvent the specified SFPs. 

In FDP_R0L.1 .1 , the PP/ST author should specify the list of operations that can be rolled back. 

In FDP_R0L.1.1, the PP/ST author should specify the information and/or list of objects that are subjected to 
the rollback policy. 

In FDP_R0L.1.2, the PP/ST author should specify the boundary limit to which rollback operations may be 
performed. The boundary may be specified as a predefined period of time, for example, operations may be 
undone which were performed within the past two minutes. Other possible boundaries may be defined as the 
maximum number of operations allowable or the size of a buffer. 

F.I 0.3 FDP_R0L.2 Advanced rollback 

F.10.3.1 User application notes 

This component enforces that the TSF provide the capability to rollback all operations; however, the user can 
choose to rollback only a part of them. 

F.10.3.2 Operations 

F.10.3.2.1 Assignment 

In FDP_R0L.2.1, the PP/ST author should specify the access control SFP{s) and/or information flow control 
SFP{s) that will be enforced when performing rollback operations. This is necessary to make sure that roll 
back is not used to circumvent the specified SFPs. 

In FDP_R0L.2.1, the PP/ST author should specify the list of objects that are subjected to the rollback policy. 

In FDP_ROL.2.2, the PP/ST author should specify the boundary limit to which rollback operations may be 
performed. The boundary may be specified as a predefined period of time, for example, operations may be 
undone which were performed within the past two minutes. Other possible boundaries may be defined as the 
maximum number of operations allowable or the size of a buffer. 

F.11 Stored data integrity (FDP.SDI) 
F.1 1.1 Usernotes 

This family provides requirements that address protection of user data while it fs stored within the TSC. 

Hardware glitches or errors may affect data stored in memory. This family provides requirements to detect 
these unintentional errors. The integrity of user data while stored on storage devices within the TSC are also 
addressed by this family. 

To prevent a subject from modifying the data, the Information flow control functions (FDPJFF) or Access 
control functions (FDP_ACF) families are required (rather than this family). 

This family differs from Intemal TOE transfer (FDPJTT) that protects the user data from Integrity enx)rs while 
being transfen-ed within the TOE. 
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F.11.2 =FDP_SDI.1 Stored data integrity monitoring 

F.11.2.1 User application notes 

This component monitors data stored on media for integrity errors. The PP/ST author can specify different 
l<inds of user data attributes that will be used as the basis for monitoring. 

F.1 1.2.2 Operations 

F.1 1.2.2.1 Assignment 

In FDP_SDI.1 .1 , the PP/ST author should specify the integrity errors that the TSF will detect. 

In FDP_SDI.1 .1 . the PP/ST author should specify the user data attributes that will be used as the basis for the 
monitoring. 

F.11.3 FDP_SDi.2 Stored data integrity monitoring and action 

F.11.3.1 User application notes 

This component monitors data stored on media for integrity errors. The PP/ST author can specify which action 
should be taken in case an integrity error is detected. 

F.1 1.3.2 Operations 

F.1 1.3.2.1 Assignment 

In FDP_SDI.2.1 , the PP/ST author should specify the integrity errors that the TSF will detect. 

In FDP_SDI.2.1, the PP/ST author should specify the user data attributes that will be used as the basis for the 
monitoring. 

In FDP_SDI.2.2, the PP/ST author should specify the actions to be taken in case an integrity error is detected. 

F.I 2 Inter-TSF user data confidentiality transfer protection (FDP_UCT) 

F.I 2.1 User notes 

This family defines the requirements for ensuring the confidentiality of user data when it is transferred using 
an external channel between the TOE and another trusted IT product. Confidentiality is enforced by 
preventing unauthorised disclosure of user data in transit between the two end points. The end points may be 
a TSF or a user. 

This family provides a requirement for the protection of user data during transit. In contrast, Confidentiality of 
exported TSF data (FPTJTC) handles TSF data. 

F.I 2.2 FDP_UCT.1 Basic data excliange confidentiality 

F.I 2.2.1 User application notes 

The TSF has the ability to protect from disclosure some user data which is exchanged. 
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F.1 2.2.2 Operations 

F.I 2.2.2.1 Assignment 

In FDP_UCT.1.1, the PP/ST author should specify the access control SFP{s) and/or information flow control 
SFP(s) that will be enforced when exchanging user data. The specified policies will be enforced to make 
decisions about who can exchange data and which data can be exchanged. 

F.I 2.2.2.2 Selection 

In FDP_UCT.1.1, the PP/ST author should specify whether this element applies to a mechanism that 
transmits or receives user data. 

F.1 3 Inter-TSF user data integrity transfer protection (FDP_UIT) 

F.I 3.1 Usernotes 

This family defines the requirements for providing integrity for user data in transit between the TSF and 
another trusted tT product and recovering from detectable errors. At a minimum, this family monitors the 
integrity of user data for modifications. Furthermore, this family supports different ways of xx^rrecting detected 
integrity errors. 

This family defines the requirements for providing integrity for user data in transit; while Integrity of exported 
TSF data (FPTJTI) handles TSF data. 

Inter-TSF user data integrity transfer protection (FDP_UIT) and Inter-TSF user data confidentiality transfer 
protection (FDP_UCT) are duals of each other, as Inter-TSF user data confidentiality transfer protection 
(FDP_UCT) addresses user data confidentiality. Therefore, the same mechanism that implements Inter-TSF 
user data integrity transfer protection (FDP_UIT) could possibly be used to implement other families such as 
Inter-TSF user data confidentiality transfer protection (FDP_UCT) and Import from outside TSF control 
(FDPJTC). 

F.1 3.2 FDP_UIT.1 Data exchange integrity 

F.1 3.2.1 User application notes 

The TSF has a basic ability to send or receive user data in a manner such that modification of the user data 
can be detected. There is no requirement for a TSF mechanism to attempt to recover fl-om the modification. 

F.1 3.2.2 Operations 

F.13.2.2.1 Assignment 

In FDP_UIT.1.1, the PP/ST author should specify the access control SFP(s) and/or information flow control 
SFP(s) that will be enforced on the transmitted data or on the received data. The specified policies will be 
enforced to make decisions about who can transmit or who can receive data, and which data can be 
transmitted or received. 

F.1 3.2.2.2 Selection 

In FDP_UIT.1 .1 , the PP/ST author should specify whether this element applies to a TSF that is transmitting or 
receiving objects. 

In FDP_UIT.1.1, the PP/ST author should specify whether the data should be protected from modification, 
deletion, insertion or replay. 

in FDP_U!T.1.2, the PP/ST author should specify whether the errors of the type: modification, deletion, 
insertion or replay are detected. 
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F.13,3 FDP_UIT.2 Source data exchange recovery 

F.t3.3.1 User applicatfon notes 

This component provides the ability to recover from a set of identified transmission errors, if required, with the 
help of the other trusted IT product. As the other trusted IT product is outside the TSC, the TSF cannot control 
its behaviour. However, it can provide functions that have the ability to cooperate with the other trusted IT 
product for the purposes of recovery. For example, the TSF could include functions that depend upon the 
source trusted IT product to re-send the data in the event that an error is detected. This component deals with 
the ability of the TSF to handle such an error recovery. 

F.I 3.3.2 Operations 

F.I 3.3.2.1 Assignment 

In FDP_UIT.2.1, the PP/ST author should specify the access control SFP(s) and/or information flow control 
SFP(s) that will be enforced when recovering user data. The specified policies will be enforced to make 
decisions about which data can be recovered and how it can be recovered. 

In FDP_UIT.2.1, the PP/ST author should specify the list of integrity errors from which the TSF, with the help 
of the source trusted IT product, is be able to recover the original user data. 

F.I 3.4 FDP_UIT.3 Destination data exchange recovery 

F.I 3.4.1 User application notes 

This component provides the ability to recover from a set of identified transmission errors. It accomplishes this 
tasit without help from the source trusted IT product. For example, if certain errors are detected, the 
transmission protocol must be robust enough to allow the TSF to recover from the error based on checksums 
and other information available within that protocol. 

F. 13.4.2 Operations 

F.13.4.2.1 Assignment 

In FDP_UIT.3.1, the PP/ST author should specify the access control SFP(s) and/or information flow control 
SFP(s) that will be enforced when recovering user data. The specified policies will be enforced to make 
decisions about which data can be recovered and how it can be recovered. 

In FDP_UIT.3.1, the PP/ST author should specify the list of integrity errors from which the receiving TSF, 
alone, is able to recover the original user data. 
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Annex G 

(normative) 

C^ass FIA: Identification and authentication 



A common security requirement is to unambiguously identify tlie person and/or entity performing functions in a 
TOE. This involves not only establishing the claimed identity «f each user, but also verifying that each user is 
indeed who he/she claims to be. This is achieved by requiring users to provide the TSF with some information 
that is known by the TSF to be associated with the user in question. 

Families in this class address the requirements for functions to establish and verify a claimed user identity. 
Identification and Authentication is required to ensure that users are associated with the proper security 
attributes (e.g. identity, groups, roles, security or integrity levels). 

The unambiguous identification of authorised users and the correct association of security attributes with 
users and subjects is critical to the enforcement of the security policies. 

The User identification (FIA_UID) family addresses determining the identity of a user. 

The User authentication (FIA_UAU) family addresses verifying the identity of a user. 

The Authentication failures (FIA_AFL) family addresses defining limits on repeated unsuccessful 
authentication attempts. 

The User attribute definition (FIA_ATD) family address the definition of user attributes that are used in the 
enforcement of the TSP. 

The User-subject binding (FIA_USB) family addresses the correct association of security attributes for each 
authorised user. 

The Specification of secrets (FIA_SOS) family addresses the generation and verification of secrets that satisfy 
a defined metric. 

Figure G.1 shows the decomposition of this class into its constituent components. 
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FIA AFL: Authentication failures 



FIA ATD: User attribute definilioii 



FIA_SOS; Specification of secrets 



K=; 



FIA UAU: User autlientication 



FIA UID: User identification 



FIA_USB: User-subject binding 




Figure G.I - FIA: Identification and authentication class decomposition 

G.I Authentication failures (FIA.AFL) 

G.1.1 Usernotes 

This family addresses requirements for defining values for authentication attempts and TSF actions in cases 
of authentication attempt failure. Parameters include, but are not limited to, the number of attempts and time 
thresholds. 

The session establishment process is the interaction with the user to perform the session establishment 
independent of the actual implementation. If the number of unsuccessful authentication attempts exceeds the 
indicated threshold, either the user account or the terminal (or both) will be locked. If the user account is 
disabled, the user cannot log-on to the system. If the terminal is disabled, the terminal (or the address that the 
terminal has) cannot be used for any log-on. Both of these situations continue until the condition for re- 
establishment is satisfied. 

G.I. 2 FIA_AFL.1 Authentication failure handling 

G.I. 2.1 User application notes 

The PP/ST author may define the number of unsuccessful authentication attempts or may choose to let the 
TOE developer or the authorised user to define this number. The unsuccessful authentication attempts need 
not be consecutive, but rather related to an authentication event. Such an authentication event could be the 
count from the last successful session establishment at a given terminal. 
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The PP/ST author could specify a list of actions that the TSF shall take in the case of authentication failure. An 
authorised administrator could also be allowed to manage the events, if deemed opportune by the PP/ST 
author. These actions could be, among other things, terminal deactivation, user account deactivation, or 
administrator alarm. The conditions under which the situation will be restored to normal must be specified on 
the action. 

In order to prevent denial of service, TOEs usually ensure that there is at least one user account that cannot 
be disabled. 

Further actions for the TSF can be stated by the PP/ST author, including rules for re-enabling the user session 
establishment process, or sending an alarm to the administrator. Examples of these actions are: until a 
specified time has lapsed, until the authorised administrator re-enables the terminal/account, a time related to 
failed previous attempts (every time the attempt fails, the disabling time is doubled). 

G.I. 2.2 Operations 

G. 1.2.2.1 Selection 

In FIA_AFL.1.1, the PP/ST author should select either the assignment of a positive integer, or the phrase "an 
administrator configurable positive integer" specifying the range of acceptable values. 

G. 1.2.2.2 Assignment 

In F!A_AFL.1.1, the PP/ST author should specify the authentication events. Examples of these authentication 
events are: the unsuccessful authentication attempts since the last successful authentication for the indicated 
user identity, the unsuccessful authentication attempts since the last successful authentication for the current 
terminal, the number of unsuccessful authentication attempts in the last 10 minutes. At least one 
authentication event must be specified. 

In FIA_AFL.1.1. if the assignment of a positive integer is selected, the PP/ST author should specify the default 
number (positive integer) of unsuccessful authentication attempts that, when met or surpassed, will trigger the 
events. 

In FIA_AFL 1.1, if an administrator configurable positive integer is selected, the PP/ST author should specify 
the range of acceptable values from which the administrator of the TOE may configure the number of 
unsuccessful authentication attempts. The number of authentication attempts should be less than or equal to 
the upper bound and greater or equal to the lower bound values. 

In 1=IA_AFL.1.2, the PP/ST author should specify the actions to be taken in case the threshold is met or 
surpassed. These actions could be disabling of an account for 5 minutes, disabling the terminal for an 
increasing amount of time (2 to the power of the number of unsuccessful attempts in seconds), or disabling of 
the account until unlocked by the administrator and simultaneously informing the administrator. The actions 
should specify the measures and if applicable the duration of the measure (or the conditions under which the 
measure will be ended). 

G.2 User attribute definition (FIA_ATD) 

G.2.1 User notes 

All authorised users may have a set of security attributes, other than the user's identity, that are used to 
enforce the TSP. This family defines the requirements for associating user security attributes with users as 
needed to support the TSP. 

There are dependencies on the individual security policy definitions. These individual definitions should 
containthe listing of attributes that are necessary for policy enforcement. 
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G.2.2 FIA_ATD.1 User attribute definition 
G.2.2.1 User application notes 

This component specifies the security attributes that should be maintained at the level of the user This means 
that the security attributes listed are assigned to and can be changed at the level of the user In other words 
changing a security attribute in this list associated with a user should have no impact on the security attributes 
of any other user. 

In case security attributes belong to a group of users (such as Capability List for a group), the user will need to 
have a reference (as security attribute) to the relevant group. 

G.2.2.2 Operations 

G.2.2.2.1 Assignment 

In FiA_ATD.1.1. the PP/ST author should specify the security attributes that are associated to an individual 
user. An example of such a list is {"clearance", "group identifier", "rights"}. 

G.3 Specification of secrets (FIA_SOS) 
G.3.1 User notes 

This family defines requirements for mechanisms that enforce defined quality metrics on provided secrets, and 
generate secrets to satisfy the defined metric. Examples of such mechanisms may include automated 
checking of user supplied passwords, or automated password generation. 

A secret can be generated outside the TOE (e.g. selected by the user and introduced in the system). In such 
cases, the FIA_S0S.1 Verffication of secrets component can be used to ensure that the external generated 
secret adheres to certain standards, for example a minimum size, not present in a dictionary and/or not 
previously used. 

Secrets can also be generated by the TOE. In those cases, the FIA_S0S.2 TSF Generation of secrets 
component can be used to require the TOE to ensure that the secrets that will adhere to some specified 
metrics. 

Secrets contain the authentication data provided by the user for an authentication mechanism that is based on 
knowledge the user possesses. When cryptographic keys are employed, the class FCS: Cryptographic 
support should be used instead of this family. 

G.3.2 FIA.SOS.I Verification of secrets 

G.3.2.1 User application notes 

Secrets can be generated by the user. This component ensures that those user generated secrets can be 
verified to meet a certain quality metric. 

G.3.2.2 Operations 

G.3.2.2.1 Assignment 

In FIA_S0S.1.1. the PP/ST author should provide a defined quality metric. The quality metric specification can 
be as simple as a description of the quality checks to be performed, or as formal as a reference to a 
government published standard that defines the quality metrics that secrets must meet. Examples of quality 
metrics could include a description ef the alphanumeric structure of acceptable secrets and/or the space size 
that acceptable secrets must meet. 
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G.3.3 FIA_S0S.2 TSF Generation of secrets 

G.3.3.1 User application notes 

This component allows the TSF to generate secrets for specific functions such as authentication by means of 
passwords. 

When a pseudo-random number generator is used in a secret generation algorithm, it should accept as Input 
random data that would provide output that has a high degree of unpredictability. This random data (seed) can 
be derived from a number of available parameters such as a system clock, system registers, date, time, etc. 
The parameters should be selected to ensure that the number of unique seeds that can be generated from 
these inputs should be at least equal to the minimum number of secrets that must be generated. 

G.3.3.2 Operations 

G.3.3.2.1 Assignment 

in FIA_S0S.2.1. the PP/ST author should provide a defined quality metric. The quality metric specification can 
be as simple as a description of the quality checks to be performed or as formal as a reference to a 
government published standard that defines the quality metrics that secrets must meet. Examples of quality 
metrics could include a description of the alphanumeric structure of acceptable secrets and/or the space size 
that acceptable secrets must meet. 

In FIA_SOS.2.2. the PP/ST author should provide a list of TSF functions for which the TSF generated secrets 
must be used. An example of such a function could include a password based authentication mechanism. 

G.4 User authentication (FIA_UAU) 

G.4.1 User notes 

This family defines the types of user authentication mechanisms supported by the TSF. This family defines the 
required attributes on which the user authentication mechanisms must be based. 

G.4.2 FIA_UAU.1 Timing of autlientication 

G.4.2.1 User application notes 

This component requires that the PP/ST author define the TSF-mediated actions that can be performed by the 
TSF on behalf of the user before the claimed identity of the user is authenticated. The TSF-mediated actions 
should have no security concerns with users incorrectly identifying themselves prior to being authenticated. 
For ail other TSF-mediated actions not in the list, the user must be authenticated before the action can be 
performed by the TSF on behalf of the user. 

This component cannot control whether the actions can also be performed before the identification took place. 
This requires the use of either FIA_UID.1 Timing of identification and FIA_UID.2 User identification before any 
action with the appropriate assignments. 

G.4.2.2 Operations 

G.4.2.2.1 Assignment 

In FIA_UAU.1.1, the PP/ST author should specify a list of TSF-mediated actions that can be performed by the 
TSF on behalf of a user before the claimed identity of the user is authenticated. This list cannot be empty. If 
no actions are appropriate, component FIA_UAU.2 User authentication before any action should be used 
instead. An example of such an action might include the request for help on the login procedure. 
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G.4.3 FiA_UAU.2 User authentication before any action 

G.4.3.1 User application notes 

This component requires that a user is authenticated before any TSF-mediated action can take place on 
behalf of that user. 

G.4.4 FIA_UAU.3 Unforgeable authentication 

G. 4.4.1 User application notes 

This component addresses requirements for mechanisms that provide protection of authentication data. 
Authentication data that is copied from another user, or is in some way constructed should be detected and/or 
rejected. These mechanisms provide confidence that users authenticated by the TSF are actually who they 
claim to be. 

This component may be useful only with authentication mechanisms that are based on authentication data 
that cannot be shared (e.g. biometrics). It is impossible for a TSF to detect or prevent the sharing of 
passwords outside the control of the TSF. 

G. 4.4.2 Operations 

G.4.4.2.1 Selection 

In FIA_UAU.3.1, the PP/ST author should specify whether the TSF will detect, prevent, or detect and prevent 
forging of authentication data. 

In FIA_UAU.3.2, the PP/ST author should specify whether the TSF will detect, prevent, or detect and prevent 
copying of authentication data. 

G.4.5 FIA_UAU.4 Single-use authentication mechanisms 

G.4.5.1 User application notes 

This component addresses requirements for authentication mechanisms based on single-use authentication 
data. Single-use authentication data can be something the user has or knows, but not something the user is. 
Examples of single-use authentication data include single-use passwords, encrypted time-stamps, and/or 
random numbers from a secret lookup table. 

The PP/ST author can specify to which authentication mechanism(s) this requirement applies. 

G.4.5.2 Operations 

G.4.5.2.1 Assignment 

In FIA_UAU.4.1. the PP/ST author should specify the list of authentication mechanisms to which this 
requirement applies. This assignment can be "all authentication mechanisms". An example of this assignment 
could be "the authentication mechanism employed to authenticate people on the external network". 

G.4.6 FiA_UAU.5 Multiple authentication mechanisms 

G.4.6.1 User application notes 

The use of this component allows specification of requirements for more than one authentication mechanism 
to be used within a TOE. For each distinct mechanism, applicable requirements must be chosen from the FIA: 
Identification and authentication class to be applied to each mechanism. It is possible that the same 
component could be selected multiple times in order to reflect different requirements for the different use of 
the authentication mechanism. 
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The management functions in the class FMT may provide maintenance capabilities for the set of 
authentication mechanisms, as well as the rules that determine whether the authentication was successful. 

To allow anonymous users to be on the system, a "none" authentication mechanism can be incorporated. The 
use of such access should be clearly explained in the rules of FIA_UAU.52. 

G.4.6.2 Operations 

G.4.6.2.1 Assignment 

In FIA_UAU.5 1, the PP/ST author should define the available authentication mechanisms. An example of 
such a list could be: "none, password mechanism, biometric (retinal scan). S/key mechanism". 

In FIA_UAU.5.2, the PP/ST author should specify the rules that describe how the authentication mechanisms 
provide authentication and when each is to be used. This means that for each situation the set of mechanisms 
that might be used for authenticating the user must be described. An example of a list of such rules is: "if the 
user has special privileges a password mechanism and a biometric mechanism both shall be used, with 
success only if both succeed; for all other users a password mechanism shall be used." 

The PP/ST author might give the boundaries within which the authorised administrator may specify specific 
rules. An example of a rule is: "the user shall always be authenticated by means of a token; the administrator 
might specify additional authentication mechanisms that also must be used." The PP/ST author also might 
choose not to specify any boundaries but leave the authentication mechanisms and their rules completely up 
to the authorised administrator. 

G.4.7 FIA_UAU.6 Re-authentlcating 

G.4.7.1 User application notes 

This component addresses potential needs to re-authenticate users at defined points in time. These may 
include user requests for the TSF to perform security relevant actions, as well as requests from non-TSF 
entities for re-authentication (e.g. a server application requesting that the TSF re-authenticate the client it is 
serving). 

G.4.7.2 Operations 

G.4.7.2.1 Assignment 

In FIA_UAU.6.1, the PP/ST author should specify the list of conditions requiring re-authentication. This list 
could include a specified user inactivity period that has elapsed, the user requesting a change in active 
security attributes, or the user requesting the TSF to perform some security critical function. 

The PP/ST author might give the boundaries within which the reauthentication should occur and leave the 
specifics to the authorised administrator. An example of such a rule is: "the user shall always be re- 
authenticated at least once a day; the administrator might specify that the re-authentication should happen 
more often but not more often than once every 10 minutes." 

G.4.8 FIA_UAU.7 Protected authentication feedback 

G.4.8.1 User application notes 

This component addresses the feedback on the authentication process that will be provided to the user, in 
some systems the feedback consists of indicating how many characters have been typed but not showing the 
characters themselves, in other systems even this information might not be appropriate. 

This component requires that the authentication data is not provided as-is back to the user. In a workstation 
environment, it could display a "dummy" (e.g. star) for each password character provided, and not the original 
character. 



176 



IS 14990 (Part 2): 2006 
ISO/iEC 15408-2: 2005 

G.4.8.2 Operations 

G.4.8.2.1 Assignment 

In FIA_UAU.7.1, the PP/ST author should specify the feedback related to the authentication process that will 
be provided to the user. An example of a feedback assignment is "the number of characters typed", another 
type of feedback is "the authentication mechanism that failed the authentication". 

G.5 User identification (FiA_UID) 

G.5.1 User notes 

This family defines the conditions under which users are required to identify themselves before performing any 
other actions that are to be mediated by the TSF and that require user identification. 

G.5.2 FIA_UID.1 Timing of identification 

G.5.2.1 User application notes 

This component poses requirements for the user to be identified. The PP/ST author can indicate specific 
actions that can be perfomned before the Identification takes place. 

tf FIA_UID.1 Timing of identification is used, the TSF-mediated actions mentioned in FIA_UID.1 Timing of 
identification should also appear in this FIA_UAU.1 Timing of authentication. 

G.5.2.2 Operations 

G.b.2.2.1 Assignment 

in F1A_UID.1.1. the PP/ST author should specify a list of TSF-mediated actions that can be performed by the 
TSF on behalf of a user before the user has to identify itself. If no actions are appropriate, component 
FIA_UID.2 User identification before any action should be used instead. An example of such an action might 
include the request for help on the login procedure. 

G.5.3 FIA_UID.2 User identification before any action 

G.5.3.1 User application notes 

in this component useis will be identified. A user is not allowed by the TSF to perform any action before being 
identified. 

G.6 User-subject binding (FIA_USB) 

G.6.1 User notes 

An authenticated user, in order to use the TOE, typically activates a subject. The user's security attributes are 
associated (totally or partially) with this subject. This family defines requirements to create and maintain the 
association of the user's security attributes to a subject acting on the user's behalf. 

G.6.2 FIA_USB.1 User-subject binding 

G.6.2.1 User application notes 

The phrase "acting on behalf of has proven to be a contentious issue in source criteria. It is intended that a 
subject is acting on behalf of the user who caused the subject to come into being or to be activated to perform 
a certain task. 
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Therefore, when a subject is created, that subject is acting on behalf of the user who initiated the creation. In 
cases where anonymity is used, the subject is still acting on behalf of a user, but the identity of that user is 
unknown. A special category of subjects are those subjects that serve multiple users (e.g. a server process). 
In such cases the user that created this subject is assumed to be the "owner". 

G.6.2.2 Operations 

G.6.2.2.1 Assignment 

In FIA_USB.1.1, the.PP/ST author should specify a list of the user security attributes that are to be bound to 
subjects. 

In FIA_USB.1.2, the PP/ST author should specify any rules that are to apply upon initial association of 
attributes with subjects, or "none". 

In FIA_USB.1.3, the PP/ST author should specify any rules that are to apply when changes are made to the 
user security attributes associated with subjects acting on behalf of users, or "none". 
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Annex H 

(normative) 

Class FMT: Security management 



This class specifies the management of several aspects of the tSF: security attributes, TSF data and 
functions in the TSF. The different management roles and their Interaction, such as separation of capability, 
can also be specified 

In an environment where the TOE is made up of multiple physically separated parts that fomi a distributed 
system, the timing issues with respect to propagation of security attributes, TSF data, and function 
modification become very complex, especially if the information is required to be replicated across the parts of 
the TOE. This should be considered when selecting components such as FMT_REV.1 Revocation, or 
FMT_SAE.1 Time-limited authorisation, where the behaviour might be impaired. In such situations, use of 
components from Internal TOE TSF data replication consistency (FPT_TRC) is advisable. 

Figure H.1 shows the decomposition of this class into its constituent components. 



FMTMOF: Management of fimctions in TSF 



FMT_MSA: Management of security attributes 



FMT_MTD: Management of TSF data 



FMT REV: Revocation 



FMT_SAE: Security attribute expiration 



FMT_SMF: Specification of Management Functions 1 



FMT_SMR: Security management roles 



Figure H.1 - FMT: Security management class decomposition 
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H.I Management of functions in TSF (FMT_MOF) 

H.1.1 User notes 

The TSF management functions enable authorised users to set up and control the secure operation of the 
TOE. These administrative functions typically fall into a number of different categories: 

a) Management functions that relate to access control, accountability and authentication controls enforced 
by the TOE. For example, definition and update of user security characteristics (e.g. unique identifiers 
associated with user names, user accounts, system entry parameters) or definition and update of auditing 
system controls (e.g. selection of audit events, management of audit trails, audit trail analysis, and audit 
report generation), definition and update of per-user policy attributes (such as user clearance), definition 
of known system access control labels, and control and management of user groups. 

b) Management functions that relate to controls over availability. For example, definition and update of 
availability parameters or resource quotas. 

c) Management functions that relate to general installation and configuration. For example, TOE 
configuration, manual recovery, installation of TOE security fixes (if any), repair and reinstallation of 
hardware. 

d) Management functions that relate to routine control and maintenance of TOE resources. For example, 
enabling and disabling peripheral devices, mounting of removable storage media, backup and recovery of 
user and system objects. 

Note that these functions need to be present in a TOE based on the families included in the PP or ST. It is the 
responsibility of the PP/ST author to ensure that adequate functions will be provided to manage the system in 
a secure fashion. 

The TSF might contain functions that can be controlled by an administrator. For example, the auditing 
functions could be switched off, the time synchronisation could be switchable, and/or the authentication 
mechanism could be modifiable. 

H.1.2 FMT_M0F.1 Management of security functions behaviour 

H.1.2.1 User application notes 

This component allows identified roles to manage the security functions of the TSF. This might entail obtaining 
the current status of a security function, disabling or enabling the security function, or modifying the behaviour 
of the security function. An example of modifying the behaviour of the security functions is changing of 
authentication mechanisms. 

H.1.2.2 Operations 

H.I. 2.2.1 Selection 

In FMT_M0F.1.1, the PP/ST author should select whether the role can determine the behaviour of, disable, 
enable, and/or modify the behaviour of the security functions. 

1-1.1.2.2.2 Assignment 

In FMT_M0F.1.1, the PP/ST author should specify the functions that can be modified by the identified roles. 
Examples include auditing and time determination. 

In FMT_M0F.1.1, the PP/ST author should specify the roles that are allowed to modify the functions in the 
TSF. The possible roles are specified in FMT_SMR.1 Security roles. 
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H.2 Management of security attributes (FIVIT_MSA) 
H.2.1 Usernotes 

This family defines the requirements on the management of security attributes. 

Users, subjects and objects have associated security attributes that will affect the behaviour of the TSF. 
Examples of such security attributes are the groups to which a user belongs, the roles he/she might assume, 
the priority of a process (subject), and the rights belonging to a role or a user. These security attributes might 
need to be managed by the user, a subject or a specific authorised user (a user with explicitly given rights for 
this management). 

It is noted that the right to assign rights to users is itself a security attribute and/or potentially subject to 
management by FMT_MSA.1 Management of security attributes. 

FMT_MSA.2 Secure security attributes can be used to ensure that any accepted combination of security 
attributes is within a secure state. The definition of what "secure" means is left to the TOE guidance and the 
TSP model. If the developer provided a clear definition of the secure values and the reason why they should 
be considered secure, the dependency from FMT_MSA.2 Secure security attributes to ADV_SPI\/I.1 Informal 
TOE security policy model can be argued away. 

In some instances subjects, objects or user accounts are created. If no explicit values for the related security 
attributes are given, default values need to be used. FMT_MSA.1 Management of security attributes can be 
used to specify that these default values can be managed. 

H.2.2 FMT_MSA.1 Management of security attributes 

H.2.2.1 User application notes 

This component allows users acting in certain roles to manage identified security attributes. The users are 
assigned to a role within the component FMT_SMR.1 Security roles. 

The default value of a parameter is the value the parameter takes when it is instantiated without specifically 
assigned values. An initial value is provided during the instantiation (creation) of a parameter, and overrides 
the default value. 

H.2.2.2 Operations 

H.2.2. 2.1 Assignment 

In FMT_MSA.1.1, the PP/ST author should list the access control SFP or the information flow control SFP for 
which the security attributes are applicable. 

H.2.2.2.2 Selection 

In FMT_MSA.1.1, the PP/ST author should specify the operations that can be applied to the identified security 
attributes. The PP/ST author can specify that the role can modify the default value (change_default), query, 
modify the security attribute, delete the security attributes entirely or define their own operation. 

H.2.2.2.3 Assignment 

In FMT_MSA.1.1, the PP/ST author should specify the security attributes that can be operated on by the 
identified roles. It is possible for the PP/ST author to specify that the default value such as default access- 
rights can be managed. Examples of these security attributes are user-clearance, priority of service level, 
access control list, default access rights. 

In FMT_MSA.1.1, the PP/ST author should specify the roles that are allowed to operate on the security 
attributes. The possible roles are specified in FMT_SMR.1 Security roles. 
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in FMT_MSA.1.1, if selected, the PP/ST author should specify which other operations the role coufd perform. 
An example of such an operation could be "create". 

H.2.3 FIVIT_MSA.2 Secure security attributes 

H.2.3.1 User application notes 

This component contains requirements on the values that can be assigned to security attributes The assigned 
values should be such that the TOE will remain in a secure state. 

The definition of what "secure" means is not answered in this component but is left to the development of the 
TOE (specifically ADV_SPM.1 Informal TOE security policy model) and the resulting information in the 
guidance. An example could be that if a user account is created, it should have a non-trivial password. 

H.2.4 FMT .MSA.3 Static attribute initialisation 

H.2.4.1 User application notes 

This component requires that the TSF provide default values for relevant object security attributes, which can 
be overridden by an initial value. It may still be possible for a new object to have different security attributes at 
creation, if a mechanism exists to specify the permissions at time of creation. 

H.2.4.2 Operations 

H.2.4.2.1 Assignment 

In FMT„MSA.3.1, the PP/ST author should list the access control SFP or the information flow control SFP for 
which the security attributes are applicable. 

H.2.4.2.2 Selection 

In FMT_MSA.3.1 , the PP/ST author should select whether the default property of the access control attribute 
Will be restrictive, permissive, or another property. In case of another property, the PP/ST author should refine 
this to a specific property. Only one of these options may be chosen. 

H.2.4.2.3 Assignment 

In FMT_MSA.3.1, if the PP/ST author selects another property, the PP/ST author should specify the desired 
characteristics of the default values. 

In FMT_MSA.3.2, ihe PP/ST author should specify the roles that are allowed to modify the values of the 
security attributes. The possible roles are specified in FMT_SMR.1 Security roles. 

H.3 Management of TSF data (F[WIT_MTD) 
H.3.1 User notes 

This component imposes requirements on the management of TSF data. Examples of TSF data are the 
current time and the audit trail. So, for example, this family allows the specification of whom can read delete 
or create the audit trail. 

H.3.2 FIWIT^MTD.I {Management of TSF data 

H.3.2.1 User application notes 

This component allows users with a certain role to manage values of TSF data. The users are assigned to a 
role within the component FMT_SMR.1 Security roles. 
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The default value of a parameter is the values the parameter takes when it is instantiated without specifically 
assigned values. An initial value is provided during the instantiation (creation) of a parameter and overrides 
the default value. 

H.3.2.2 Operations 

H.3.2.2.1 Selection 

In FMT_MTD.1.1, the PP/ST author should specify the operations that can be applied to the identified TSF 
data. The PP/ST author can specify that the role can modify the default value (change_default) clear query 
or modify the TSF data, or delete the TSF data entirely. If so rfesired the PP/ST author could specify any type 
of operation. To clarify^clear TSF data" means that the content of the TSF data is removed but that the entity 
itself remains in the system. 

H.3.2.2.2 Assignment 

In FMT_MTD.1.1. the PP/ST author should specify the TSF data that can be operated on by the identified 
roles. It IS possible for the PP/ST author to specify that the default value can be managed. 

In FMT_MTD.1.1, the PP/ST author should specify the roles that are allowed to operate on the TSF data The 
possible roles are specified in FMT_SMR.1 Security roles. 

In FMT_MTD.1.1, if selected, the PP/ST author should specify which other operations the role could perform 
An example could be "create". 

H.3.3 FMT_MTD.2 Management of limits on TSF data 

H.3.3.1 User application notes 

This component specifies limits on TSF data, and actions to be tal<en if these limits are exceeded This 
component, for example, will allow limits on the size of the audit trail to be defined, and specification of the 
actions to be taken when these limits are exceeded. 

H.3.3.2 Operations 

H.3.3.2.1 Assignment 

In FMT_MTD.2.1, the PP/ST author should specify the TSF data that can have limits, and the value of those 
limits. An example of such TSF data is the number of users togged-in. 

In FMT_MTD.2.1, the PP/ST author should specify the roles that are allowed to modify the limits on the TSF 
data and the actions to be taken. The possible roles are specified in FMT_SMR.1 Security roles. 

xor'^J-'^^^^"^' *^® ^^'^^ ^^^^°^ ^^^^^^ ®P®^'^ ^^® ^^*'°"5 ^° ^^ ^^l^en if the specified limit on the specified 
TSF data IS exceeded. An example of such TSF action is that the authorised user is informed and an audit 
record is generated. 

H.3.4 FMT_MTD.3 Secure TSF data 

H.3.4.1 User application notes 

This component covers requirements on the values that can be assigned to TSF data The assigned values 
should be such that the TOE will remain in a secure state. 

The definition of what "secure" means is not answered in this component but is left to the development of the 
TOE (specifically ADV_SPM.1 Informal TOE security policy model) and the resulting information in the 
guidance. If the developer provided a clear definition of the secure values and the reason why they should be 
considered secure, the dependency from FMT_MSA.3 Static attribute initialisation to ADV SPM 1 Informal 
TOE security policy model can be argued away. 
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H.4 Revocation (FMT_REV) 
H.4.1 User notes 

This family addresses revocation of security attributes for a variety of entities within a TOE. 

H.4.2 FMT_REV.1 Revocation 

H.4.2.1 User application notes 

This component specifies requirements on the revocation of rights. It requires the specification of the 
revocation rules. Examples are: 

a) Revocation will take place on the next login of the user; 

b) Revocation will take place on the next attempt to open the file; 

c) Revocation will take place within a fixed time. This might mean that all open connections are re-evaluated 
every x minutes. 

H.4.2.2 Operations 

H.4.2.2.1 Selection 

In FMT_REV.1 .1 . the PP/ST author should specify whether the ability to revoke security attributes from users, 
subjects, objects, or any additional resources shall be provided by the TSF. 

hl.4.2.2.2 Assignment 

In FMT_REV.1.1, the PP/ST author should specify the roles that are allowed to modify the functions in the 
TSF. The possible roles are specified in FMT_SMR.1 Security roles. 

In FMT_REV.1.1, the PP/ST author should, if additional resources is selected, specify whether the ability to 
revoke their security attributes shall be provided by the TSF. 

In FMT_REV.1.2, the PP/ST author should specify the revocation rules. Examples of these rules could 
include: "prior to the next operation on the associated resource", or "for all new subject creations". 

H.5 Security attribute expiration (FIWIT_SAE) 

H.5.1 User notes 

This family addresses the capability to enforce time limits for the validity of security attributes. This family can 
be applied to specify expiration requirements for access control attributes, identification and authentication 
attributes, certificates (key certificates such as ANSI X509 for example), audit attributes, etc. 

H.5.2 FMT_SAE.1 Time-limited authorisation 

H.5.2.1 Operations 

H.5.2.1.1 Assignment 

In FMT_SAE.1.1, the PP/ST author should provide the list of security attributes for which expiration is to be 
supported. An example of such an attribute might be a user's security clearance. 

In FMT_SAE.1.1, the PP/ST author should specify the roles that are allowed to modify the security attributes 
in the TSF. The possible roles are specified in FMT_SMR.1 Security roles. 
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In FIVtT_SAE.1 .2, the PP/ST author should provide a list of actions to be taken for each security attribute when 
it expires. An example might be that the user's security clearance, when it expires, is set to the lowest 
allowable clearance on the TOE. If immediate revocation is desired by the PP/ST, the action "immediate 
revocation" should be specified. 

H.6 Specification of Management Functions (FMT_SMF) 
H.6.1 Usernotes 

This family allows the specification of the management functions to be provided by the TOE. Each security 
management function that is listed in ftjifilling the assignment is either security attribute management, TSF 
data management, or security function management. 

H.6.2 FMT_SMF.1 Specification of lUanagement Functions 

H.6.2.1 User application notes 

This component specifies the management functions to be provided. 

PP/ST authors should consult the "Management" subclauses for components included in their PP/ST to 
provide a basis for the management functions to be listed via this component. 

H.6.2.2 Operations 
H.6.2.2.1 Assignment 

In FMT_SMF.1.1, the PP/ST author should specify the management functions to be provided by the TSF 
either security attribute management, TSF data management, or security function management. 

H.7 Security management roles (FMT_SMR) 
H.7.1 Usernotes 

This family reduces the likelihood of damage resulting from users abusing their authority by taking actions 
outside their assigned functional responsibilities. It also addresses the threat that inadequate mechanisms 
have been provided to securely administer the TSF. 

This family requires that information be maintained to identify whether a user is authorised to use a particular 
security-relevant administrative function. 

Some management actions can be performed by users, others only by designated people within the 
organisation. This family allows the definition of different roles, such as owner, auditor, administrator daily- 
management. 

The roles as used in this family are security related roles. Each role can encompass an extensive set of 
capabilities (e.g. root in UNIX), or can be a single right (e.g. right to read a single object such as the helpfile). 
This family defines the roles. The capabilities of the role are defined in Management of functions In TSF 
(FMT_MOF), Management of security attributes (FMT_MSA) and Management of TSF data (FMT_MTD). 

Some type of roles might be mutually exclusive. For example the daily-management might be able to define 
and activate users, but might not be able to remove users (which is reserved for the administrator (role)). This 
class will allow policies such as two-person control to be specified. 
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H.7.2 FMT_SMR.1 Security roles 

H.7.2.1 User application notes 

This component specifies the different roles that the TSF should recognise. Often the system distinguishes 
between the owner of an entity, an administrator and other users. 

1-1.7.2.2 Operations 

H.7.2.2.1 Assignment 

In FMT_SMR.1.1, the PP/ST author should specify the roles that are recognised by the system. These are the 
roles that users could occupy with respect to security. Examples are: owner, auditor and administrator. 

H.7.3 FMT_SMR.2 Restrictions on security roles 

H.7.3.1 User application notes 

This component specifies the different roles that the TSF should recognise, and conditions on how those roles 
could be managed. Often the system distinguishes between the owner of an entity, an administrator and other 
users. 

The conditions on those roles specify the interrelationship between the different roles, as well as restrictions 
on when the role can be assumed by a user. 

H.7.3.2 Operations 

H.7.3.2.1 Assignment 

In FMT_SMR.2.1 , the PP/ST author should specify the roles that are recognised by the system. These are the 
roles that users could occupy with respect to security. Examples are: owner, auditor, administrator. 

In FMT_SMR.2.3, the PP/ST author should specify the conditions that govern role assignment. Examples of 
these conditions are: "an account cannot have both the auditor and administrator role" or "a user with the 
assistant role must also have the owner role". 

H.7.4 FMT_SMR.3 Assuming roles 

H. 7.4.1 User application notes 

This component specifies that an explicit request must be given to assume the specific role. 

H.7.4.2 Operations 

H.7.4.2.1 Assignment 

In FMT_SMR.3.1, the PP/ST author should specify the roles that require an explicit request to be assumed. 
Examples are: auditor and administrator. 
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Annex I 

(normative) 

Class FPR: Privacy 



This class describes the requirements that could be levied to satisfy the users' privacy needs, while still 
allowing the systenn flexibility as far as possible to maintain sufficient control over the operation of the system. 

in the components of this class there is flexibility as to whether or not authorised users are covered by the 
required security functions. For example, a PP/ST author might consider it appropriate not to require 
protection of the privacy of users against a suitably authorised user. 

This class, together with other classes (such as those concerned with audit, access control, trusted path, and 
non-repudiation) provides the flexibility to specify the desired privacy behaviour. On the other hand, the 
requirements in this class might impose limitations on the use of the components of other classes, such as 
FtA: Identification and authentication or FAU: Security audit. For example, if authorised users are not allowed 
to see the user identity (e.g. Anonymity or Pseudonymity), it will obviously not be possible to hold individual 
users accountable for any security relevant actions they perform that are covered by the privacy requirements. 
However, it may still be possible to include audit requirements in a PP/ST, where the fact that a particular 
security relevant event has occurred is more important than knowing who was responsible for it. 

Additional information is provided in the application notes for class ^AU: Security audit, where it is explained 
that the definition of "identity" in the context of auditing can also be an alias or other information that could 
identify a user. 

This class describes four families: Anonymity, Pseudonymity, Unlinkability and Unobservability. Anonymity, 
Pseudonymity and Unlinkability have a complex interrelationship. When choosing a family, the choice should 
depend on the threats identified. For some types of privacy threats, pseudonymity will be more appropriate 
than anonymity (e.g. if there is a requirement for auditing). In addition, some types of privacy threats are best 
countered by a combination of components from several families. 

All families assume that a user does not explicitly perform an action that discloses the user's own identity. For 
example, the TSF is not expected to screen the user name in electronic messages or databases. 

All families in this class have components that can be scoped through operations. These operations allow the 
PP/ST author to state the cooperating users/subjects to which the TSF must be resistant. An example of an 
instantiation of anonymity could be: " The TSF shall ensure that the users and/or subjects are unable to 
determine the user identity bound to the teleconsulting application". 

It is noted that the TSF should not only provide this protection against individual users, but also against users 
cooperating to obtain the information. The strength of the protection provided by this class should be 
described as strength of function as specified in annexes A and B of ISO/IEC 15408-1. 

Figure 1.1 shows the decomposition of this class into its constituent components. 
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Figure 1.1 - FPR: Privacy class decomposition 
1.1 Anonymity (FPR_ANO) 
1.1.1 User notes 

Anonymity ensures that a subject may use a resource or service without disclosing its user identity. 

The intention of this family is to specify that a user or subject might take action without releasing its user 
identity to others such as users, subjects, or objects. The family provides the PP/ST author with a means to 
identify the set of users that cannot see the identity of someone performing certain actions. 

Therefore if a subject, using anonymity, performs an action, another subject will not be able to determine 
either the identity or even a reference to the identity of the user employing the subject. The focus of the 
anonymity is on the protection of the users identity, not on the protection of the subject identity; hence, the 
identity of the subject Is not protected from disclosure. 

Although the identity of the subject is not released to other subjects or users, the TSF is not explicitly 
prohibited from obtaining the users identity. In case the TSF is not allowed to know the identity of the user, 
FPR_AN0.2 Anonymity without soliciting information could be invoked. In that case the TSF should not 
request the user information. 

The interpretation of "determine" should be taken in the broadest sense of the word. The PP/ST author might 
want to use a Strength of Function to indicate how much rigour should be applied. 

The component levelling distinguishes between the users and an authorised user. An authorised user is often 
excluded from the component, and therefore allowed to retrieve a user's identity. However, there is no specific 
requirement that an authorised user must be able to have the capability to determine the user's identity. For 
ultimate privacy the components would be used to say that no user or authorised user can see the identity of 
anyone performing any action. 

Although some systems will provide anonymity for all services that are provided, other systems provide 
anonymity for certain subjects/operations. To provide this flexibility, an operation is included where the scope 
of the requirement is defined. If the PP/ST author wants to address all subjects/operations, the words "all 
subjects and all operations" could be provided. 

Possible applications include the ability to make enquiries of a confidential nature to public databases, 
respond to electronic polls, or make anonymous payments or donations. 
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Examples of potential hostile users or subjects are providers, system operators, communication partners and 
users, who smuggle malicious parts (e.g. Trojan Horses) into systems. All of these users can investigate 
usage patterns (e.g. which users used which services) and misuse this information. 

1.1.2 FPR_AN0.1 Anonymity 

1.1.2.1 User application notes 

This component ensures that the identity of a user is protected from disclosure. There may be instances 
however that a igiven authorised user can determine who performed certain actions. This component gives 
the flexibility to capture either a limited or total privacy policy. 

1.1.2.2 Operations 
1.1.2.2.1 Assignment 

In FPR_AN0.1.1, the PP/ST author should specify the set of users and/or subjects against which the TSF 
mus provide protection. For example, even if the PP/ST author specifies a single user or subject role the TSF 
must not only provide protection against each individual user or subject, but must protect with respect to 
cooperating users and/or subjects. A set of users, for example, could be a group of users which can operate 
under the same role or can all use the same process(es). 

In FPR ANO.1.1. the PP/ST author should identify the list of subjects and/or operations and/or objects where 
the real user name of the subject should be protected, for example, "the voting application". 

1.1 .3 FPR_AN0.2 Anonymity without soliciting information 

1.1.3.1 User application notes 

This component is used to ensure that the TSF is not allowed to know the identity of the user. 

1.1.3.2 Operations 
1.1.3.2.1 Assignment 

In FPR_AN0.2.1, the PP/ST author should specify the set of users and/or subjects against which the TSF 
mus provide protection. For example, even if the PP/ST author specifies a single user or subject role the TSF 
must not only provide protection against each individual user or subject, but must protect with respect to 
cooperating users and/or subjects. A set of users, for example, could be a group of users which can operate 
under the same role or can all use the same process(es). 

In FPR ANO.2.1. the PP/ST author should identify the list of subjects and/or operations and/or objects where 
the real user name of the subject should be protected, for example, "the voting application". 

■s 

In FPR_AN0^2.2, the PP/ST author should identify the list of services which are subject to the anonvmitv 
requirement, for example, "the accessing of job descriptions". 

In FPR_ANa22, the PP/ST author should identify the list of subjects from which the real user name of the 
subject should be protected when the specified services are provided. 

1.2 Pseudonymlty (FPR^PSE) 

1.2.1 User notes 

Pseudonymlty ensures that a user may use a resource or service without disclosing its identity but can still be 
accountable for that use. The user can be accountable by directly being related to a reference (alias) held by 
the TSF, or by providing an alias that will be used for processing purposes, such as an account number 
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In several respects, pseudonymity resembles anonymity. Both pseudonymity and anonymity protect the 
identity of the user, but in pseudonymity a reference to the user's identity is maintained for accountability or 
other purposes. 

The component FPR_PSE.1 Pseudonymity does not specify the requirements on the reference to the user's 
identity. For the purpose of specifying requirements on this reference two sets of requirements are presented: 
FPR_PSE.2 Reversible pseudonymity and FPR_PSE.3 Alias pseudonymity. 

A way to use the reference is by being able to obtain the original user identifier. For example, in a digital cash 
environment it would be advantageous to be able to trace the user's identity when a check has been issued 
multiple times (i.e. fraud). In general, the user's identity needs to be retrieved under specific conditions. The 
PP/ST author might want to incorporate FPR_PSE.2 Reversible pseudonymity to describe those services. 

Another usage of the reference is as an alias for a user. For example, a user who does not wish to be 
identified, can provide an account to which the resource utilisation should be charged. In such cases, the 
reference to the user identity is an alias for the user, where other users or subjects can use the alias for 
performing their functions without ever obtaining the user's identity (for example, statistical operations on use 
of the jsystem). In this case, the PP/ST author might wish to incorporate FPR_PSE.3 Alias pseudonymity to 
specify the rules to which the reference must conform. 

Using these constructs above, digital money can be created using FPR_PSE.2 Reversible pseudonymity 
specifying that the user identity will be protected and, if so specified in the condition, that there be a 
requirement to trace the user identity if the digital money is spent twice. When the user is honest, the user 
identity is protected; if the user tries to cheat, the user identity can be traced. 

A different kind of system could be a digital credit card, where the user will provide a pseudonym that 
indicates an account from which the cash can be subtracted. In such cases, for example, FPR_PSE.3 Alias 
pseudonymity could be used. This component would specify that the user identity will be protected and, 
furthermore, that the same user will only get assigned values for which he/she has provided money (if so 
specified in the conditions). 

It should be realised that the more stringent components potentially cannot be combined with other 
requirements, such as identification and authentication or audit. The interpretation of "determine the identity- 
should be taken in the broadest sense of the word. The information is not provided by the TSF during the 
operation, nor can the entity determine the subject or the owner of the subject that invoked the operation, nor 
will the TSF record information, available to the users or subjects, which might release the user identity in the 
future. 

The intent is that the TSF not reveal any information that would compromise the identity of the user, e.g. the 
identity of subjects acting on the user's behalf. The information that is considered to be sensitive depends on 
the effort an attacker is capable of spending. Therefore, the Pseudonymity (FPR_PSE) family is subject to 
Strength of Function requirements. 

Possible applications inckjde the ability to charge a caller for premium rate telephone services without 
disclosing his or her identity, or to be charged for the anonymous use of an electronic payment system. 

Examples oT potential hostile users are providers, system operators, communication partners and users, who 
smuggle malicious parts (e.g. Trojan Horses) into systems. All of these attackers can investigate which users 
used which services and misuse this information. Additionally to Anonymity services, Pseudonymity Services 
contains methods for authorisation without identification, especially for anonymous payment ("Digital Cash"). 
This helps providers to obtain their payment in a secure way while maintaining customer anonymity. 

1.2.2 FPR_PSE.1 Pseudonymity 

1.2.2.1 User application notes 

This component provides the user protection against disclosure of identity to other users. The user will remain 
accountable for its actions. 
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1.2.2.2 Operations 

1.2.2.2.1 Assignment 

In FPR_PSE.1.1, the PP/ST author should specify the set of users and/or subjects against which the TSF 
must provide protection. For example, even if the PP/ST author specifies a single user or subject role, the TSF 
must not only provide protection against each individual user or subject, but must protect with respect to 
cooperating users and/or subjects. A set of users, for example, could be a group of users which can operate 
under the same role or can all use the same process(es). 

In FPR_PSE.1.1. the PP/ST author should identify the list ofisubjects and/or operations and/or objects where 
the real user name of the subject should be protected, for example, "the accessing of job offers". Note that 
"objects" includes any other attributes that might enable another user or subject to derive the actual identity of 
the user. 

In FPR_PSE.1,2, the PP/ST author should identify the (one or more) number of aliases the TSF is able to 
provide. 

In FPR_PSE.1.2, the PP/ST author should identify the list of subjects to whom the TSF is able to provide an 
alias. 

1.2.2.2.2 Selection 

In FPR_PSE.1.3. the PP/ST author should specify whether the user alias is generated by the TSF, or supplied 
by the user. Only one of these options may be chosen. 

1.2.2.2.3 Assignment 

In FPR_PSE.1.3, the PP/ST author should identify the metric to which the TSF-generated or user-generated 
alias should conform. 

1.2.3 FPR_PSE.2 Reversible pseudonymity 

1.2.3.1 User application notes 

In this component, the TSF shall ensure that under specified conditions the user identity related to a provided 
reference can be determined. 

in FPR_PSE.1 Pseudonymity the TSF shall provide an alias instead of the user identity. When the specified 
conditions are satisfied, the user identity to which the alias belong can be determined. An example of such a 
condition in an electronic cash environment is: " The TSF shall provide the notary a capability to determine the 
user identity based on the provided alias only under the conditions that a check has been issued twice.". 

1.2.3.2 Operations 
1.2.3.2.1 Assignment 

In FPR_PSE.2.1. the PP/ST author should specify the set of users and/or subjects against which the TSF 
must provide protection. For example, even if the PP/ST author specifies a single user or subject role, the TSF 
must not only provide protection against each individual user or subject, but must protect with respect to 
cooperating users and/or subjects. A set of users, for example, could be a group of users which can operate 
under the same role or can all use the same process(es). 

In FPR_PSE.2.1, the PP/ST author should identify the list of subjects and/or operations and/or objects where 
the real user name of the subject should be protected, for example, "the accessing of job offers". Note that 
"objects" includes any other attributes that might enable another user or subject to derive the actual identity of 
the user. 
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In FPR_PSE.2.2, the PP/ST author should identify the (one or more) number of aliases the TSF is able to 
provide. 

In FPR_PSE.2;2, the PP/ST author should identify the list of subjects to whom the TSF is able to provide an 
alias. 

1.2.3.2.2 Serection 

In FPR_PSE.2.3, the PP/ST author should specify whether the user alias is generated by the TSF or supplied 
by the user. Only one of these options may be chosen. 

t.2.3.2.3 Assignment 

In FPR_PSE.2.3, the PP/ST author should identify the metric to which the TSF-generated or user-qenerated 
alias should conform. 

1.2.3.2.4 Selection 

In FPR_PSE.2.4, the PP/ST author should select whether the authorised user and/or trusted subjects can 
determine the real user name. 

1.2.3.2.5 Assignment 

In FPR_PSE.2.4, the PP/ST author should identify the list of conditions under which the trusted subjects and 
authorised user can determine the real user name based on the provided reference. These conditions can be 
conditions such as time of day, or they can be administrative such as on a court order. 

In FPR_PSE.2.4, the PP/ST author should identify the list of trusted subjects that can obtain the real user 
name under a specified condition, for example, a notary or special authorised user. 

1.2.4 FPR_PSE.3 Alias pseudonymity 

1.2.4.1 User application notes 

In this component, the TSF shall ensure that the provided reference meets certain construction rules, and 
thereby can be used in a secure way by potentially insecure subjects. 

If a user wants to use disk resources without disclosing its identity, pseudonymity can be used However 
every time the user accesses the system, the same alias must be used. Such conditions can be specified iri 
this component. 

1.2.4.2 Operations 
1.2.4.2.1 Assignment 

In FPR_PSE.3.1, the PP/ST author should specify the set of users and/or subjects against which the TSF 
must provide protection. For example, even if the PP/ST author specifies a single user or subject role, the TSF 
must not only provide protection against each individual user or subject, but must protect with respect to 
cooperating users and/or subjects. A set of users, for example, coutd be a group of users which can operate 
under the same role or can all use the same process(es). 

In FPR_PSE.3.1 , the PP/ST author should identify the list of subjects and/or operations and/or objects where 
the real user name of the subject should be protected, for example, "the accessing of job offers" Note that 
"objects" includes any other attributes which might enable another user or subject to derive the actual rdentitv 
of the user. ' 

In FPR_PSE.3.2, the PP/ST author should identify the (one or more) number of aliases the TSF is able to 
provide. 
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In PPR_PSE.3.2, the PP/^ST author should identify the list of subjects to whom the TSF is able to provide an 
alias. 

1.2.4.2.2 Selection 

In FPR_PSE.3.3. the PP/ST author should specify whether the user alias is generated by the TSF, or supplied 
by the user. Only one of these options may be chosen. 

1.2.4.2.3 Assignment 

In FPR_PSE.3.3, the PP/ST author should identify the metric to which the TSF-generated or user-generated 
alias should conform. 

In FPR_PSE.3.4. the PP/ST author should identify the list of conditions that indicate when the used reference 
for the real user name shall be identical and when it shall be different, for example, "when the user logs on to 
the same host" it will use a unique alias. 

1.3 Unlinkability (FPR_UNL) 

1.3.1 User notes 

Unlinkability ensures that a user may make multiple uses of resources or services without others being able to 
link these uses together. Unlinkability differs from pseudonymity that, although in pseudonymity the user is 
also not known, relations between different actions can be provided. 

The requirements for unlinkability are intended to protect the user identity against the use of profiling of the 
operations. For example, when a telephone smart card is employed with a unique number, the telephone 
company can determine the behaviour of the user of this telephone card. When a telephone profile of the 
users is known, the card can be linked to a specific user. Hiding the relationship between different invocations 
of a service or access of a resource will prevent this kind of information gathering. 

As a result, a requirement for unlinkability could imply that the subject and user identity of an operation must 
be protected. Othenwise this information might be used to link operations together. 

Unlinkability requires that different operations cannot be related. This relationship can take several forms. For 
example, the user associated with the operation, or the terminal which initiated the action, or the time the 
action was executed. The PP/ST author can specify what kind of relationships are present that must be 
countered. 

Possible applications include the ability to make multiple use of a pseudonym without creating a usage pattern 
that might disclose the user's identity. 

Examples for potential hostile subjects and users are providers, system operators, communication partners 
and users, who smuggle malicious parts, (e.g. Trojan Horses) into systems, they do not operate but want to 
get information about. All of these attackers can investigate (e.g. which users used which services) and 
misuse this information. Unlinkability protects users from linkages, which could be drawn between several 
actions of a customer. An example is a series of phone calls made by an anonymous customer to different 
partners, where the combination of the partner's identities might disclose the identity of the customer. 

1.3.2 FPR_UNL.1 Unlinkability 

1.3.2.1 User application notes 

This component ensures that users cannot link different operations in the system and thereby obtain 
information. 
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1.3.2.2 Operations 

1.3.2.2.1 Assignment 

In FPR_UNL.1.1, the PP/ST author should specify the set of users and/or subjects against which the TSF 
must provide protection. For example, even if the PP/ST author specifies a single user or subject role, the TSF 
must not only provide protection against each individual user or subject, but must protect with respect to 
cooperating users and/or subjects. A set of users, for example, could be a group of users which can operate 
under the same role or can all use the same process(es). 

In FPR_UNL.1.1, the PP/ST author should identify the list of operations which should be subjected to the 
unllnkability requirement, for example, "sending email". 

1.3.2.2.2 Selection 

In FPR_UNL.1.1, the PP/ST author should select the relationships that should be obscured. The selection 
allows either the user identity or an assignment of relations to be specified. 

1.3.2.2.3 Assignment 

In FPR_UNL.1.1, the PP/ST author should identify the list of relations which should be protected against, for 
example, "originate from the same terminal". 

1.4 Unobservability (FPR„UNO) 
1.4.1 User notes 

Unobservability ensures that a user may use a resource or service without others, especially third parties, 
being able to observe that the resource or service is being used. 

Unobservability approaches the user identity from a different direction than the previous families Anonymity, 
Pseudonymity and Unllnkability. In this case, the intent is to hide the use of a resource or service, rather than 
to hide the user's identity. 

A number of techniques can be applied to implement unobservability. Examples of techniques to provide 
unobservability are: 

a) Allocation of information impacting unobservability: Unobservability relevant information (e.g. information 
that describes that an operation occurred) can be allocated in several locations within the TOE. The 
information might be allocated to a single randomly chosen part of the TOE such that an attacker does 
not know which part of the TOE should be attacked. An alternative system might distribute the information 
such that no single part of the TOE has sufficient information that, if circumvented, the privacy of the user 
would be compromised. This technique is explicitly addressed in FPR_UN0.2 Allocation of information 
impacting unobservability. 

b) Broadcast: When information is broadcast (e.g. ethernet, radio), usert ;tinot determine who actually 
received and used that Information. This technique is especially useful when information should reach 
receivers which have to fear a stigma for being interested in that information (e.g. sensitive medical 
information). 

c) Cryptographic protection and message padding: People observing a message stream might obtain 
information from the fact that a message is transferred and from attributes on that message. By traffic 
padding, message padding and encrypting the message stream, the transmission of a message and its 
attributes can be protected. 

Sometimes, users should not see the use of a resource, but an authorised user must be allowed to see the 
use of the resource in order to perform his duties. In such cases, the FPR_UN0.4 Authorised user 
observability could be used, which provides the capability for one or more authorised users to see the usage. 
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This family makes use of tlie concept "parts of the TOE". This is considered any part of the TOE that is either 
physically or logically separated from other parts of the TOE. In the case of logical separation Domain 
separation (FPT_SEP) may be relevant. 

Unobservability of communications may be an important factor in maay areas, such as the enforcement of 
constitutional rights, organisational policies, or in defence related applications. 

1.4.2 FPR_UN0.1 Unobservability 

1.4.2.1 User application notes 

This component requires that the use of a function or resource cannot be observed by unauthorised users. In 
addition to this component, a PP/ST author might want to incorporate Covert Channel Analysis. 

1.4.2.2 Operations 

1.4.2.2.1 Assignment 

In FPR_UN0.1.1. the PP/ST author should specify the list of users and/or subjects against which the TSF 
must provide protection. For example, even if the PP/ST author specifies a single user or subject role, the TSF 
must not only provide protection against each individual user or subject, but must protect with respect to 
cooperating users and/or subjects. A set of users, for example, could be a group of users which can operate 
under the same role or can all use the same process(es). 

In FPR_UN0.1.1, the PP/ST author should identify the list of operations that are subjected to the 
unobservability requirement. Other users/subjects will then not be able to observe the operations on a covered 
object in the specified list (e.g. reading and writing to the object). 

In FPR_UN0.1 .1 , the PP/ST author should identify the list of objects which are covered by the unobservability 
requirement. An example could bea specific mail server or ftp site. 

In FPR_UN0.1.1, the PP/ST author should specify the set of protected users and/or subjects whose 
unobservability information will be protected. An example could be: "users accessing the system through the 
internet". 

1.4.3 FPR_UN0.2 Allocation of information impacting unobservability 

1.4.3.1 User application notes 

This component requires that the use of a function or resource cannot be observed by specified users or 
subjects. Furthermore this component specifies that information related to the privacy of the user is distributed 
within the TOE such that attackers might not know which part of the TOE to target, or they need'to attack 
multiple parts of the TOE. 

An example of the use of this component is the use of a randomly allocated node to provide a function. In 
such a case the component might require that the privacy related information shall only be available to one 
identified part of the TOE, and will not be communicated outside this part of the TOE. 

A more complex example can be found in some "voting algorithms". Several parts of the TOE will be involved 
in the service, but no individual part of the TOE will be able to violate the policy. So a person may cast a vote 
(or not) without the TOE being able to determine whether a vote has been cast and what the vote happened to 
be (unless the vote was unanimous). 

In addition to this component, a PP/ST author might want to incorporate Covert Channel Analysis. 
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1.4.3.2 Operations 
1.4.3.2.1 Assignment 

In FPR_UN0.2.1, the PP/ST author should specify the list of users and/or subjects against which the TSF 
must provide protection. For example, even if the PP/ST author specifies a single user or subject role, the TSF 
must not only provide protection against each individual user or subject, but must protect with respect to 
cooperating users and/or subjects. A set of users, for example, could be a group of users which can operate 
under the same role or can all use the same process(es). 

In FPR_UN0.2.1, the PP/ST author should identify the list of operations that are subjected to the 
unobservability requirement. Other users/subjects will then not be able to observe the operations on ^ covered 
object in the specified list (e.g. reading and writing to the object). 

In FPR_UN0.2.1, the PP/ST author should identify the list of objects which are covered by the unobservability 
requirement. An example could be a specific mail server or ftp site. 

In FPR_UN0.2.1, the PP/ST author should specify the set of protected users and/or subjects whose 
unobservability information will be protected. An example could be: "users accessing the system through the 
internet". 

In FPR_UN0.2.2, the PP/ST author should identify which privacy related information should be distributed in a 
controlled manner. Examples of this information could be: IP address of subject, IP address of object, time, 
used encryption keys. 

In FPR_UN0.2.2, the PP/ST author should specify the conditions to which the dissemination of the 
information should adhere. These conditions should be maintained throughout the lifetime of the privacy 
related information of each instance. Examples of these conditions could be: "the information shall only be 
present at a single separated part of the TOE and shall not be communicated outside this part of the TOE.", 
"the information shall only reside in a single separated part of the TOE, but shall be moved to another part of 
the TOE periodically", "the information shall be distributed between the different parts of the TOE such that 
compromise of any 5 separated parts of the TOE will not compromise the security policy". 

1.4.4 FPR_UN0.3 Unobservability witiiout soliciting information 

1.4.4.1 User application notes 

This component is used to require that the TSF does not try to obtain information that might compromise 
unobservability when provided specific services. Therefore the TSF will not solicit (i.e. try to obtain from other 
entities) any information that might be used to compromise unobservability. 

1.4.4.2 Operations 
1.4.4.2.1 Assignment 

In FPR_UN0.3.1, the PP/ST author should identify the list of services which are subject to the unobservability 
requirement, for example, "the accessing of job descriptions". 

In FPR_UN0.3.1, the PP/ST author should identify the list of subjects from which privacy related information 
should be protected when the specified services are provided. 

In FPR_UN0.3.1, the PP/ST author should specify the privacy related information that will be protected from 
the specified subjects. Examples include the identity of the subject that used a service and the quantity of a 
service that has been used such as memory resource utilisation. 



196 



IS 14990 (Part 2) : 2006 
ISO/IEC 15408-2: 2005 

1.4.5 FPR_UN0.4 Authorised user observability 

1.4.5.1 User application notes 

This component is used to require that there will be one or more authorised users with the rights to view the 
resource utilisation. Without this component, this review is allowed, but not mandated. 

1.4.5.2 Operations 

1.4.5.2.1 Assignment 

In FPR_UN0.4.1 , the PP/ST author should specify the set of authorised users for which the TSF must provide 
the capability to observe the resource utilisation. A set of authorised users, for example, could be a group of 
authorised users which can operate under the-same role or can all use the same process(es). 

In FPR_UN0.4.1, the PP/ST author should specify the set of resources and/or services that the authorised 
user must be able to observe. 
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Annex J 

(normative) 

Class FPT: Protection of the TSF 



This class contains families of functional requirements that relate to the integrity and management of the 
mechanisms that provide the TSF (independent of TSP-specifics) and to the integrity of TSF data 
{independent of the specific contents of the TSP data). In some sense, families in this class may appear to 
duplicate components in the FDP: User data protection class; they may even be implemented using the same 
mechanisms. However, FDP: User data protection focuses on user data protection, while FPT: Protection of 
the TSF focuses on TSF data protection. In fact, components from the FPT: Protection of the TSF class are 
necessary to provide requirements that the SFPs in the TOE cannot be tampered with or bypassed. 

From the point of view of this class, there are three significant portions that make up the TSF: 

a) The TSF's abstract machine, which is the virtual or physical machine upon which the specific TSF 
implementation under evaluation executes. 

b) The TSF's implementation, which executes on the abstract machine and implements the mechanisms 
that enforce the TSP. 

c) The TSF's data, which are the administrative databases that guide the enforcement of the TSP. 

All of the families in the FPT: Protection of the TSF class can be related to these areas, and fall into the 
following groupings: 

a) TSF physical protection (FPT_PHP), which provides an authorised user with the ability to detect external 
attacks on the parts of the TOE that comprise the TSF. 

b) Underlying abstract machine test (FPT_AMT) and TSF self test (FPT_TST), which provide an authorised 
user with the ability to verify the correct operation of the underlying abstract machine and the TSF as well 
as the integrity of the TSF data and executable code. 

c) Domain separation (FPT_SEP) and Reference mediation (FPT_RVM), which protect the TSF during 
execution and ensure that the TSF cannot be bypassed. When appropriate components from these 
families are combined with the appropriate components from TSF internals (ADVJNT), the TOE can be 
5aid to have what has been traditionally called a "Reference Monitor." 

d) Trusted recovery (FPT_RCV), Fail secure (FPT_FLS), and Internal TOE TSF data replication consistency 
{FPT_TRC), which address the behaviour of the TSF when failure occurs and immediately after. 

e) Availability of exported TSF data (FPT_ITA), Confidentiality of exported TSF data (FPTJTC), Integrity of 
exported TSF data (FPTJTI), which address the protection and availability of TSF data between the TSF 
and a remote trusted IT product. 

f) Internal TOE TSF data transfer (FPTJTT), which addresses protection of TSF data when it is transmitted 
between physically-separated parts of the TOE. 

g) Replay detection (FPT_RPL), which addresses the replay of various types of information and/or 
operations. 

h) State synchrony protocol (FPT_SSP), which addresses the synchronisation of states, based upon TSF 
data, between different parts of a distributed TSF. 

i) Time stamps (FPT_STM), which addresses reliable timing. 
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j) Inter-TSF TSF data consistency (FPT_TDC), which addresses the consistency of TSF data shared 
between the TSF and a remote trusted IT product. 

Figure J.I shows the decomposition of this class into its constituent components. 



FPT AMI: Underlying abstract machine test 



FPT FLS: Fail seaire 



FPTJTA: Availability of exported TSF data 



FPT_rrC: Confidentiality of exported TSF data 



FPT_m: Integrity of exported TSF data 



FPT ITT; Internal TOE TSF data transfer 



FPT_PHP: TSF physical protection 



FPT_RC"V: Tni&tedrecovery 



FPT_RPL: Replay detection 



FPT RVM: Reference mediation 



FPTSEP: Domain separation 



FPT_SSP: State synchrony protocol 



FPTSTM: Time stanips 



FPT_TDC: Inter-TSF TSF data consistency 



FPTTRC: Internal TOE TSF data replication consistency 1 



FPT TST: TSF self test 



Figure J.I - FPT: Protection of the TSF class decomposition 
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J.I Underlying abstract machine test (FPT_AMT) 
J. 1.1 Usernotes 

This family defines the requirements for the TSPs testing of security assumptions made about the underivina 
abstract machine upon which the TSF relies. This "abstract" machine x^ould be a hardware/firmware platform 
or It could be some known and assessed hardware/software combination acting as a virtual machine' 
Examples of such testing could be testing hardware page protection, sending sample packets across a 
network to ensure receipt, and verifying the behaviour of the virtual machine interface. These tests can be 
i^''^15? °"* ®'*'^®^ '" so"^® maintenance state, at start-up. on-line, or continuously. The actions to be taken by 
the TOE as the result of testing are defined in Trusted recovery (FPT_RCV). 

The term "undertying abstract machine" typically refers to the hardware components upon which the TSF has 
been implemented. However, the phrase can also be used to refer to an underlying, previously evaluated 
hardware and software combination behaving as a virtual machine upon which the TSF relies. 

The tests of the abstract machine may take various forms: 

a) Power-On Tests. These are tests that ensure the correct operation of the underlying platform For 
hardware and firmware, this might include tests of elements such as memory boards, data paths buses 
control logic, processor registers, communication ports, console interfaces, speakers, and peripherals' 
For software elements (virtual machine), this would include verificatron of correct initialisation and 
behaviour. 

b) Loadable Tests. These are tests that might be loaded and executed by an authorised user or be activated 
by specific conditions. This might include processor component stress tests (logic units, calculation units 
etc.) and control memory. 

J. 1.2 Evaluator notes 

The tests of the underlying abstract machine should be sufficient to test all of the characteristics of the 
underlying abstract machine upon which the TSF relies. 

J.I. 3 FPT_AMT.1 Abstract machine testing 
J. 1.3.1 User application notes 

This component provides support for the periodic testing of the security assumptions of the underlyinq 
abstrac machine upon which the TSF's operation depends, by requiring the ability to periodically invoke 
testing functions. 

The PP/ST author may refine the requirement to state whether the function should be available in off-line on- 
line or maintenance mode. 

J.1.3.2 Evaluatornotes 

It is acceptable for the functions for periodic testing to be available only in an off-line or maintenance mode 
controls should be in place to limit access, during maintenance, to authorised users. 

J.I. 3.3 Operations 
J.I. 3.3.1 Selection 

In FPT_AMT.1.1, the PP/ST author should specify when the TSF will execute the abstract machine testing 
during initia start-up, periodically during normal operation, at the request of an authorised user, or under other 
conditions. In the case of the latter option, the PP/ST author should refine what those conditions are The 
PP/ST author, through this selection, has the ability to indicate the frequency with which the seff tests will be 
run. IT the tests are run often, then the end users should have more confidence that the TOE is operatina 
correctly than if the tests are run (ess frequently. However, this need for confidence thatihe TOE is operating 
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correctly must be balanced with the potential impact on the availability of the TOE, as often times, self tests 
may delay the normal operation of a TOE. 

J.1. 3.3.2 Assignment 

In FPT_AMT.1 .1 , the PP/ST author should, if other conditions is selected, specify the frequency with which the 
self tests will be run. 

J.2 Fail secure (FPT_FLS) 

J.2.1 User notes 

The requirements of this family ensure that the TOE will not violate its TSP in the event of certain types of 
failures in the TSF. 

J.2.2 FPT_FLS.1 Failure with preservation of secure state 

J.2.2.1 User application notes 

The term "secure state" refers fo a state in which the TSF data are consistent and the TSF continues correct 
enforcement of the TSP. The "secure state" is defined in the TSP model. If the developer provided a clear 
definition of the secure state and the reason why it should be considered secure, the dependency from 
FPT_FLS.1 Failure with preservation of secure state to ADV_SPM.1 Informal TOE security policy model can 
be argued away. 

Although it is desirable to audit situations in which failure with preservation of secure state occurs, it is not 
possible in all situations. The PP/ST author should specify those situations in which audit is desired and 
feasible. 

Failures in the TSF may include "hard" failures, which indicate an equipment malfunction and which may 
require maintenance, service or repair of the TSF. Failures in the TSF may also include recoverable "soft" 
failures, which may only require initialisation or resetting of the TSF. 

J.2.2.2 Operations 

J.2.2.2.1 Assignment 

In FPT_FLS.1.1, the PP/ST author should list the types of failures in the TSF for Which the TSF should "fail 
secure," that is, should preserve a secure state and continue to correctly enforce the TSP. 

J. 3 Availability of exported TSF data (FPTJTA) 

J.3.1 User notes 

This family defines the rules for the prevention of loss of availability of TSF data moving between the TSF and 
a remote trusted IT product. This data could be TSF critical data such as passwords, keys, audit data, or TSF 
executable code. 

This family is used in a distributed system, context where the TSF is providing TSF data to a remote trusted IT 
product. The TSF can only take the measures at its site and cannot be held responsible for the TSF at the 
other trusted IT product. 

If there are different availability metrics for different types of TSF data, then this component should be iterated 
for each unique pairing of metrics and types of TSF data. 
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J.3.2 FPTJTA.I Inter-TSF availability witliin a defined availability metric 
J. 3. 2.1 Operations 
J.3.2. 1.1 Assignment 

In FPTJTA.1.1, the PP/ST author should specify the types of TSF data that are subject to the availability 

metric. 

In FPTJTA.1 .1 , the PP/ST should specify the availability metric for the applicable TSF data. 

In FPTJTA.I .1 , the PP/ST author should specify the conditions under which availability must be ensured. For 
example; there must be a connection between the TOE and the remote trusted IT product. 

J.4 Confidentiality of exported TSF data (FPTJTC) 
J.4.1 User notes 

This family defines the rules for the protection from unauthorised disclosure of TSF data moving between the 
TSF and a remote trusted IT product. Examples of this data are TSF critical data such as passwords, keys, 
audit data, or TSF executable code. 

This family is used in a distributed system context where the TSF is providing TSF data to a remote trusted IT 
product. The TSF can only take the measures at its site and cannot be held responsible for the behaviour of 
the other trusted IT product. 

J.4.2 FPTJTC.1 Inter-TSF confidentiality during transmission 
J.4.2.1 Evaluator notes 

Confidentiality of TSF Data during transmission is necessary to protect such information from disclosure. 
Some possible implementations that could provide confidentiality include the use of cryptographic algorithms 
as well as spread spectrum techniques. 

J.5 Integrity of exported TSF data (FPTJTI) 

J.5.1 User notes 

This family defines the rules for the protection, from unauthorised modification, of TSF data during 
transmission between the TSF and a remote trusted IT product. Examples of this data are TSF critical data 
such as passwords, keys, audit data, or TSF executable code. 

This family is used in a distributed system context where the TSF is exchanging TSF data with a remote 
trusted IT product. Note that a requirement that addresses modification, detection, or recovery at the remote 
trusted IT product cannot be specified, as the mechanisms that a remote trusted IT product will use to protect 
its data cannot be determined in advance. For this reason, these requirements are expressed in terms of the 
"TSF providing a capability" which the remote trusted IT product can use. 

J.5.2 FPTJTI.I Inter-TSF detection of modification 

J. 5.2.1 User application notes 

This compdnent should be used in situations where it is sufficient to detect when data have been modified. An 
example of such a situation is one in which the remote trusted IT product can request the TOE's TSF to 
retransmit data when modification has been detected, or respond to such types of request. 
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The desired strength of modification detection is based upon a specified nnodification metric that is a function 
of the algorithm used, which may range from a weal< checl<sum and parity mechanisms that may fail to detect 
multiple bit changes, to more complicated cryptographic checksum approaches. 

J.5.2.2 Operations 

J.5.2.2.1 Assignment 

In FPT_ITI.1.1, the PP/ST should specify the modification metric that the detection mechanism must satisfy. 
This modification metric shall specify the desired strength of the modification detection. 

In FPT_ITI.1.2, the PP/ST should specify the actions to be taken if a modification of TSF data has been 
detected. An example of an action is: "ignore the TSF data, and request the originating trusted product to send 
the TSF data again". 

J. 5.3 FPT_ITI.2 Inter-TSF detection and correction of modification 

J.5.3.1 User application notes 

This component should be used in situations where it is necessary to detect or correct modifications of TSF 
critical data. 

The desired strength ot modification detection is based upon a specified modification metric that is a function 
of the algorithm used, which may range from a checksum and parity mechanisms that may fail to detect 
multiple bit changes, to more complicated cryptographic checksum approaches. The metric that needs to be 
defined can either refer to the attacks it will resist (e.g. only 1 in a 1000 random messages will be accepted), 
or to mechanisms that are well known in the public literature (e.g. the strength must be conformant to the 
strength offered by Secure Hash Algorithm). 

The approach taken to correct modification might be done through some form of error correcting checksum. 
J. 5.3.2 Evaluator notes 

Some possible means of satisfying this requirement involves the use of cryptographic functions or some form 
of checksum. 

J.5.3.3 Operations 

J.5. 3.3.1 Assignment 

In FPT_ITI.2.1, the PP/ST should specify the modification metric that the detection mechanism must satisfy. 
This modification metric shall specify the desired strength of the modification detection. 

In FPTJTI.2.2, the PP/ST should specify the actions to be taken if a modification of TSF data has been 
detected. An example of an action is: "ignore the TSF data, and request the originating trusted product to send 
the TSF data again". 

In FPT_ITI.2.3. the PP/ST author should define the types of modification from which the TSF should be 
capable of recovering. 

J.6 Internal TOE TSF data transfer (FPTJTT) 

J.6.1 User notes 

This family provides requirements that address protection of TSF data when it is transfen-ed between separate 
parts of a TOE across an internal channel. 

The determination of the degree of separation (i.e., physical or logical) that would make application of this 
family useful depends on the intended environment of use. In a hostile environment, there may be risks arising 
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from transfers between parts of the TOE separated by only a system bus or an inter-process communications 
channel. In more benign environments, the transfers may be across more traditional network media. 

J.6.2 Evaluator notes 

One practical mechanism available to a TSF to provide this protection is cryptographically-based. 

J.6.3 FPTJTT.1 Basic internal TSF data transfer protection 

J.6.3.1 Operations 

J.6.3.1.1 Selection 

In FPT_ITT.1.1, the PP/ST author should specify the desired type of protection to be provided from the 
choices: disclosure, modification. 

J.6.4 FPT_ITT.2 TSF data transfer separation 

J.6.4.1 User application notes 

One of the ways to achieve separation of TSF data based on SFP-relevant attributes is through the use of 
separate logical or physical channels. 

J.6.4.2 Operations 

J.6.4.2.1 Selection 

In FPT_ITT.2.1, the PP/ST author should specify the desired type of protection to be provided from the 
choices: disclosure, modification. 

J.6.5 FPTJTT.3 TSF data integrity monitoring 

J.6.5.1 Operations 

J.6.5.1.1 Selection 

In FPT_ITT.3.1, the PP/ST author should specify the desired type of modification that the TSF shall be able to 
detect. The PP/ST author should select from: modification of data, substitution of data, re-ordering of data, 
deletion of data, or any other integrity errors. 

J.6.5.1. 2 Assignment 

In FPTJTT.3. 1, if the PP/ST author chooses the latter selection noted in the preceding paragraph, then the 
author should also specify what those other integrity errors are that the TSF should be capable of detecting. 

In FPTJTT.3.2. the PP/ST author should specify the action to be taken when an integrity error is identified. 
J.7 TSF physical protection {FPT_PHP) 
J.7.1 User notes 

TSF physical protection components refer to restrictions on unauthorised physical access to the TSF, and to 
the deterrence of, and resistance to, unauthorised physical modification, or substitution of the TSF. 

The requirements in this family ensure that the TSF is protected from physical tampering and interference. 
Satisfying the requirements of these components results in the TSF being packaged and used in such a 
manner that physical tampering is detectable, or resistance to physical tampering is measurable based on 
defined work factors. Without these components, the protection functions of a TSF lose their effectiveness in 
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environments where physical damage cannot be prevented. This component also provides requirements 
regarding how the TSF must respond to physical tampering attempts. 

Examples of physical tampering scenarios include mechanical attack, radiation, changing the temperature. 

It is acceptable for the functions that are available to an authorised user for detecting physical tampering to be 
available only in an off-line or maintenance mode. Controls should be in place to limit access during such 
modes to authoriseri users. As the TSF may not be "operational" during those modes, it may not be able to 
provide normal enforcement for authorised user access. The physical implementation of a TOE might consist 
of several structures: for example an outer shielding, cards, and chips. This set of "elements" as a whole must 
protect (protect, notify and resist) the TSF from physical tampering. This does not mean that all devices must 
provide these features, but the complete physical construct as a whole should. 

Although there is only minimal auditing associating with these components, this is solely because there is the 
potential that the detection and alarm mechanisms may be implemented completely in hardware, below the 
level of interaction with an audit subsystem (for example, a hardware-based detection system based on 
breaking a circuit and lighting a light emitting diode (LED) if the circuit is broken when a button is pressed by 
the authorised user). Nevertheless, a PP/ST author may determine that for a particular anticipated threat 
environment, there is a need to audit physical tampering. If this is the case, the PP/ST author should include 
appropriate requirements in the list of audit events. Note that inclusion of these requirements may have 
implications on the hardware design and its interface to the software. 

J.7.2 FPT_PHP.1 Passive detection of physical attack 

J.7.2.1 User application notes 

FPT_PHP.1 Passive detection of physical attack should be used when threats from unauthorised physical 
tampering with parts of the TOE are not countered by procedural methods. It addresses the threat of 
undetected physical tampering with the TSF. Typically, an authorised user would be given the function to 
verify whether tampering took place. As written, this component simply provides a TSF capability to detect 
tampering. Specification of management functions in FMT_M0F.1 Management of security functions 
behaviour should be considered to specify who can make use of that capability, and how they can make use 
of that capability. If this function is realised by non-IT mechanisms (e.g. physical inspection) management 
functions are not required. 

J.7.3 FPT_PHP.2 Notification of pliysical attacic 

J.7.3.1 User application notes 

FPT_PHP.2 Notification of physicalattack should be used when threats from unauthorised physical tampering 
with parts of the TOE are not countered by procedural methods, and it is required that designated individuals 
be notified of physical tampering. It addresses the threat that physical tampering with TSF elements, although 
detected, may not be noticed. 

J.7.3.2 Operations 

J.7.3.2.1 Assignment 

In FPT_PHP.2.3, the PP/ST author should provide a list of TSF devices/elements for which active detection of 
physical tampering is required. 

In FPT_PHP.2.3, the PP/ST author should designate a user or role that is to be notified when tampering is 
detected. The type of user or role may vary depending on the particular security administration component 
(from the FMT_M0F.1 Management of security functions behaviour family) included in the PP/ST. 
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J.7.4 FPT_PHP.3 Resistance to physical attack 

J.7.4.1 User application notes 

For some forms of tampering, it is necessary that the TSF not only detects the tampering, but actually resists it 
or delays the attacker. 

This component should be used when TSF devices and TSF elements are expected to operate in an 
environment where a physical tampering (e.g. observation, analysis, or modification) of the internals of a TSF 
device or TSF element itself is a threat. 

J.7.4.2 Operations 

J.7.4.2.1 Assignment 

In FPT_PHP.3.1, the PP/ST author should specify tampering scenarios to a list of TSF devices/elements for 
which the TSF should resist physical tampering. This list may be applied to a defined subset of the TSF 
physical devices and elements based on considerations such as technology limitations and relative physical 
exposure of the device. Such subsetting should be clearly defined and justified. Furthermore, the TSF should 
automatically respond to physical tampering. The automatic response should be such that the policy of the 
device is preserved; for example, with a confidentiality policy, it would be acceptable to physically disable the 
device so that the protected information may not be retrieved. 

In FPT_PHP.3.1, the PP/ST author should specify the list of TSF devices/elements for which the TSF should 
resist physical tampering in the scenarios that have been identified. 

J.8 Trusted recovery (FPT_RCV) 

J. 8.1 User notes 

The requirements of this family ensure that the TSF can determine that the TOE is started-up without 
protection compromise and can recover without protection compromise after discontinuity of operations. This 
family is important because the start-up state of the TSF determines the protection of subsequent states. 

Recovery components reconstruct the TSF secure states, or prevent transitions to insecure states, as a direct 
response to occurrences of expected failures, discontinuity of operation or start-up. Failures that must be 
generally anticipated include the following: 

a) Unmaskable action failures that always result in a system crash (e.g. persistent inconsistency of critical 
system tables, uncontrolled transfers within the TSF code caused by transient failures of hardware or 
firmware, power failures, processor failures, communication failures). 

b) Media failures causing part or all of the media representing the TSF objects to become inaccessible or 
corrupt (e.g. parity errors, disk head crash, persistent read/write failure caused by misaligned disk heads, 
worn-out magnetic coating, dust on the disk surface). 

c) Discontinuity of operation caused by erroneous administrative action or lack of timely administrative 
action (e.g. unexpected shutdowns by turning off power, ignoring the exhaustion of critical resources, 
inadequate installed configuration). 

Note that recovery may be from either a complete or partial failure scenario. Although a complete failure might 
occur in a monolithic operating system, it is less likely to occur in a distributed environment. In such 
environments, subsystems may fail, but other portions remain operational. Further, critical components may 
be redundant (disk mirroring, alternative routes), and checkpoints may be available. Thus, recovery is 
expressed in terms of recovery to a secure state. 
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There are different interactions between Trusted recovery (FPT_RCV) and TSF self test (FPT_TST) 
components to be considered when selecting Trusted recovery (FPT_RCV): 

a) The need for trusted recovery may be indicated through the results of TSF self-testing, where the results 
of the self-tests indicate that the TSF is in an insecure state and return to a secure state or entrance in 
maintenance mode is required. 

b) A failure, as discussed above, may be identified by an administrator. Either the administrator may perform 
the actions to return the TOE to a secure state and then invoke TSF self-tests to confirm that the secure 
state has been achieved. Or, the TSF self-tests may be invoked to complete the recovery process. 

c) A combination of a. and b. above, where the need for trusted recovery is indicated through the results of 
TSF self-testing, the administrator performs the actions to return the TOE to a secure state and then 
invokes TSF self-tests to confirm that the secure state has been achieved. 

d) Self tests detect a failure/service discontinuity, then either automated recovery or entrance to a 
maintenance mode. 

This family identifies a maintenance mode. In this maintenance mode normal operation might be impossible or 
severely restricted, as othenwise insecure situations might occur. Typically, only authorised users should be 
allowed access to this mode but the real details of who can access this mode is a function of FMT: Security 
management. If FMT: Security management does not put any controls on who can access this mode, then it 
may be acceptable to allow any user to restore the system if the TOE enters such a state. However, in 
practice, this is probably not desirable as the user restoring the system has an opportunity to configure the 
TOE in such a way as to violate the TSP. 

Mechanisms designed to detect exceptional conditions during operation fall under TSF self test (FPT_TST), 
Fail secure (FPT_FLS), and other areas that address the concept of "Software Safety." It is likely that the use 
of one of these families will be required to support the adoption of Trusted recovery (FPT_RCV). This is to 
ensure that the TOE wilt be able to detect when recovery is required. 

Throughout this family, the phrase "secure state" is used. This refers to some state in which the TOE has 
consistent TSF data and a TSF that can correctly enforce the policy. This state may be the initial "boot" of a 
clean system, or it might be some checkpointed state. The "secure state" is defined in the TSP model. If the 
developer provided a clear definition of the secure state and the reason why it should be considered secure, 
the dependency from each of the components in Trusted recovery (FPT_RCV) to ADV_SPM.1 Informal TOE 
security policy model can be argued away. 

Following recovery, it may be necessary to confirm that the secure state has been achieved through self- 
testing of the TSF. However, if the recovery is performed in a manner such that only a secure state can be 
achieved, else recovery fails, then the dependency to the FPT_TST.1 TSF testing TSF self-test component 
may be argued away. 

J.fl.2 FPT_RCV.1 Manual recovery 

J.8.2.1 User application notes 

In the hierarchy of the trusted recovery family, recovery that requires only manual intervention is the least 
desirable, for it precludes the use of the system in an unattended fashion. 

This component is intended for use in TOEs that do not require unattended recovery to a secure state. The 
requirements of this componen^t reduce the threat of protection compromise resulting from an attended TOE 
returning to an insecure state after recovery from a failure or other discontinuity. 

J.8.2.2 Evaluator notes 

It is acceptable for the functions that are available to an authorised user for trusted recovery to be available 
only in a maintenance mode. Controls should be in place to limit access during maintenance to authorised 
users. 
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J.8.2.3 Operations 

J.8.2.3.1 Assignment 

In FPT_RCV.1.1, the PP/ST author should specify the list of failures or service discontinuities (e.g. power 
failure, audit storage exhaustion, any failure or discontinuity) following which the TOE will enter a maintenance 
mode. 

J.8.3 FPT_RCV.2 Automated recovery 

J.8.3.1 User application notes 

Automated recovery is considered to be more useful than manual recovery, as it allows the machine to 
operate in an unattended fashion. 

The component FPT_RCV.2 Automated recovery extends the feature coverage of FPT_RCV.1 Manual 
recovery by requiring that there be at least one automated method of recovery from failure or service 
discontinuity. It addresses the threat of protection compromise resulting from an unattended TOE returning to 
an insecure state after recovery from a failure or other discontinuity. 

J.8.3.2 Evaluator notes 

It is acceptable for the functions that are available to an authorised user for trusted recovery to be available 
only in a maintenance mode. Controls should be in place to limit access during maintenance to authorised 
users. 

For FPT_RCV.2.1, it is the responsibility of the developer of the TSF to determine the set of recoverable 
failures and service discontinuities. 

It is assumed that the robustness of the automated recovery mechanisms will be verified. 

J. 8. 3. 3 Operations 

J.8. 3.3.1 Assignment 

In FPT_RCV.2.1, the PP/ST author should specify the list of failures or service discontinuities (e.g. power 
failure, audit storage exhaustion) following which the TOE will need to enter a maintenance mode. 

In FPT_RCV.2.2, the PP/ST author should specify the list of failures or other discontinuities for which 
automated recovery must be possible. 

J.8.4 FPT_RCV.3 Automated recovery without undue loss 

J.8.4.1 User application notes 

Automated recovery is considered to be more useful than manual recovery, but it runs the risk of losing a 
substantia! number of objects. Preventing undue loss of objects provides additional utility to the recovery effort. 

The component FPT_RCV.3 Automated recovery without undue loss extends the feature coverage of 
FPT_RCV.2 Automated recovery by requiring that there not be undue loss of TSF data or objects within the 
TSC. At FPT_RC\/.2 Automated recovery, the automated recovery mechanisms could conceivably recover by 
deleting all objects and returning the TSF to a known secure state. This type of drastic automated recovery is 
precluded in FPT_RCV,3 Automated recovery without undue loss. 

This component addresses the threat of protection compromise resulting from an unattended TOE returning to 
an insecure state after recovery from a failure or other discontinuity with a large loss of TSF data or objects 
within the TSC. 
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J.8.4.2 Evaluator notes 



It is acceptable for the functions that are available to an authorised user for trusted recovery to be available 
only in a maintenance mode. Controls should be in place to limit access during maintenance to authorised 
users. 

It is assumed that the evaluators will verily the robustness of the automated recovery mechanisms. 

J.8.4.3 Operations 

J.8.4.3.1 Assignment 

In FPT_RCV.3.1, the PP/ST author should specify the list of failures or service discontinuities {e.g. power 
failure, audit storage exhaustion) following which the TOE will need to enter a maintenance mode. 

In FPT_RCV.3.2, the PP/ST author should specify the list of failures or other discontinuities for which 
automated recovery must be possible. 

in FPT_RCV.3.3, the PP/ST author should provide a quantification for the amount of loss of TSF data or 
objects that is acceptable. 

J.8.5 FPT_RCV.4 Function recovery 

J.8.5.1 User application notes 

Function recovery requires that if there should become failure in the TSF. that certain SFs in the TSF should 
either complete successfully or recover to a secure state. 

J.^.5.2 Operations 

J.8.5.2.1 Assignment 

In FPT_RCV.4.1 , the PP/ST author should specify a list the SFs and failure scenarios. In the event that any of 
the identified failure scenarios happen, the SFs that have been specified must either complete successfully or 
recover to a consistent and secure stale. 

J.9 Replay detection (FPT_RPL) 
J.9.1 User notes 

This family addresses detection of replay for various types of entities and subsequent actions to correct. 

J.9.2 FPT_RPL.1 Replay detection 

J.9.2.1 User application notes 

The entities included here are, for example, messages, service requests, service responses, or sessions. 

J.9.2.2 Operations 

J.9.2.2.1 Assignment 

In FPT_RPL.1.1, the PP/ST author should provide a list of identified entities for which detection of replay 
should be possible. Examples of such entities might include: messages, service requests, service responses, 
and user sessions. 

In FPT_RPL.1.2, the PP/ST author should specify the list of actions to be taken by the TSF when replay is 
detected. The potential set of actions that can be taken includes: ignoring the replayed entity, requesting 
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confirmation of the entity from the identified source, and terminating the subject from which the re-played 
entity originated. 

J.10 Reference mediation (FPT_RVM) 

J. 10.1 User notes 

The components of this family address the "always invoked" aspect of a traditional reference monitor. The 
goal of these components is to ensure, with respect to the TSC, that all actions requiring policy enforcement 
invoked by subjects untrusted with respect to any or all of that SFP to objects controlled by that SFP are 
validated by the TSF against the SFP. If the portion of the TSF that enforces the SFP also meets the 
requirements of appropriate components from Domain separation (FPT_SEP) and TSF internals (ADVJNT), 
than that portion of the TSF provides a "reference monitor" for that SFP. 

The Reference Monitor is that portion of the TSF responsible for the enforcement of the TSP; it has the 
following three characteristics: 

a) Untrusted subjects cannot interfere with its operation; i.e. it is tamperproof. This is addressed by the 
components in the Domain separation (FPT_SEP) family. 

b) Untrusted subjects cannot bypass its checks; i.e. it is always invoked. This is addressed by the 
components in the Reference mediation (FPT_RVM) family. 

c) It is simple enough to be analysed and its behaviour understood (i.e. its design is conceptually simple.) 
This is addressed by the components in the TSF internals (ADVJNT) family. 

This component states that, "the TSF shall ensure that TSP enforcement functions are invoked and succeed 
before each and every function within the TSC is allowed to proceed." In any system (distributed or othenwise) 
there are a finite number of functions responsible for enforcing the TSP. There is nothing in this requirement 
that mandates or prescribes that a single function is invoked to handle security. Rather, it allows multiple 
functions to fill the role of reference monitor, and the collection of them responsible for enforcing the TSP are 
simply called, collectively, the reference monitor. However, this must be balanced by the goal of keeping the 
"reference monitor" simple. 

A TSF that implements a SFP provides effective protection against unauthorised functions if and only if all 
enforceable actions (e.g. accesses to objects) requested by subjects untrusted with respect to any or all of 
that SFP are validated by the TSF before succeeding, If the enforceable action is incorrectly enforced or 
bypassed, the overall enforcement of the SFP has been compromised. "Untrusted" subjects could then 
bypass the SFP in a variety of unauthorised ways (e.g. circumvent access checks for some subjects or 
objects, bypass checks for objects whose protection was assumed by applications, retain access rights 
beyond their intended lifetime, bypass auditing of audited actions, or bypass authentication). Note that the 
term "untrusted subjects" refers to subjects untrusted with respect to any or all of the specific SFPs being 
enforced; a subject may be trusted with respect to one SFP and untrusted with respect to a different SFP. 

J.10.2 FPT.RVM.I Non-bypassabilltyoftheTSP 

J.1 0.2.1 User application notes 

In order to obtain the equivalent of a reference monitor, this component must be used with either FPT_SEP.2 
SFP domain separation or FPT_SEP.3 Complete reference monitor, and ADVJNT.3 Minimisation of 
complexity. Further, if complete reference mediation is required, the components from FDP: User data 
protection must cover all objects. 
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J.11 Domain separation (FPT^SEP) 
J.11.1 User notes 

The components of this family ensure that at least one security domain is available for the TSF's own 
execution, and that the TSF is protected from external interference and tampering (e.g. by modification of TSF 
code or data structures) by untrusted subjects. Satisfying the requirements of this family makes the TSF self- 
protecting, meaning that an untrusted subject cannot modify or damage the TSF. 

This family requires the following: 

a) The resources of the TSF's security domain ("protected domain") and those of subjects and 
unconstrained entities external to the domain are separated such that the entities external to the 
protected domain cannot observe or modify data structures or code internal to the protected domain. 

b) The transfer of subjects between domains are controlled such that arbitrary entry to, or return from, the 
protected domain is not possible. 

c) The user or application parameters passed to the protected domain by addresses are validated with 
respect to the protected domain's address space, and those passed by value are validated with respect to 
the values expected by the protected domain. 

d) The security domains of subjects are distinct except for controlled sharing via the TSF. 

This family Is needed whenever confidence is required that the TSF has not been subverted. 

in order to obtain the equivalent of a reference monitor, the components FPT_SEP.2 SFP domain separation 
or FPT_SEP.3 Complete reference monitor from this family must be used in conjunction with FPT_RVM.1 
Non-bypassabi!lty of the TSP, and ADV_INT.3 Minimisation of complexity. Further, if complete reference 
mediation is required, the components from FDP: User data protection must cover alt objects. 

J.11.2 FPT_SEP.1 TSF domain separation 

J.1 1.2.1 User application notes 

Without a separate protected domain for the TSF, there can be no assurance that the TSF has not been 
subjected to any tampering attacks by untrusted subjects. Such attacks may involve modification of the TSF 
code and/or TSF data structures. 

J.11. 3 FPT_SEP.2 SFP domain separation 

J.1 1 .3.1 User application notes 

The most important function provided by a TSF Is the enforcement of its SFPs. In order to simplify the design 
and increase the likelihood that those significant SFPs exhibit the characteristics of a reference monitor (RM), 
in particular, being tamperproof, they must be in a domain distinct from the remainder of the TSF. 

J.11.3.2 Evaluator notes 

it is possible that a reference monitor in a layered design may provide functions beyond those of the SFPs. 
This arises out of the practical nature of layered software design. The goal should be to minimise the non-SFP 
related functions. 

Note that it is acceptable for the reference monitors for all included SFPs to be in a single distinct reference 
monitor domain, as well as having multiple reference monitor domains (each enforcing one or more SFPs). If 
multiple reference monitor domains for SFPs are present, it is acceptable for them to be either peers or in a 
hierarchical relationship. 
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For FPT_SEP.2.1. the phrase "unisolated portion of the TSF" refers to that portion of the TSF consisting of 
those functions in the TSF not covered by FPT_SEP.2.3. 

J.1 1.3.3 Operations 

J. 11. 3.3.1 Assignment 

In FPT_SEP.2.3, the PP/ST author should specify the access control and/or information flow control SFPs in 
the TSP that should have a separate domain. 

J.1 1 .4 FPT_SEP.3 Complete reference monitor 

J.1 1.4.1 User application notes 

The most important function provided by a TSF is the enforcement of its SFPs. This component builds upon 
the intentions of the previous component by requiring that all access control and/or information flow control 
FSPs be enforced in a domain distinct from the remainder of the TSF. This further simplifies the design and 
increases the likelihood that the characteristics of a reference monitor (RM), in particular, being tamperproof, 
are found in the TSF. 

J.1 1 .4.2 Evaluator notes 

It is possible that a reference monitor in a layered design may provide functions beyond those of the SFPs. 
This arises out of the practical nature of layered software design. The goal should be to minimise the non-SFP 
related functions. 

Note that it is acceptable for the reference monitors for all included SFPs to be in a single distinct reference 
monitor domain, as well as having multiple reference monitor domains (each enforcing one or more SFPs). If 
multiple reference monitor domains for SFPs are present, it is acceptable for them to be either peers or in a 
hierarchical relationship. 

J.I 2 State synchrony protocol (FPT_SSP) 
J. 12.1 User notes 

Distributed systems may give rise to greater complexity than monolithic systems through the potential for 
differences in state between parts of the system, and through delays in communication. In most cases. 
synchronisation of state between distributed functions involves an exchange protocol, not a simple action. 
When malice exists in the distributed environment of these protocols, more complex defensive protocols are 
required. 

State synchrony protocol (FPT_SSP) establishes the requirement forjcertain critical security functions of the 
TSF to use a trusted protocol. State synchrony protocol (FPT_SSP) ensures that two distributed parts of the 
TOE (e.g. hosts) have synchronised their states after a security-relevant action. 

Some states may never be synchronised, or the transaction cost may be too high for practical use; encryption 
key revocation is an example, where knowing the state after the revocation action is initiated can never be 
known. Either the action was taken and acknowledgment cannot be sent, or the message was ignored by 
hostile communication partners and the revocation never occurred. Indeterminacy is unique to distributed 
systems. Indeterminacy and state synchrony are related, and the same solution may apply. It is futile to 
design for indeterminate states; the PP/ST author should express other requirements in such cases (e.g. raise 
an alarm, audit the event). 
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J.12.2 FPT_SSP.1 Simple trusted acknowledgement 
J.12.2.1 User application notes 

In this component, the TSF must supply an acknowledgement to another part of the TSF when requested. 
This acknowledgement should indicate that one part of a distributed TOE successfully received an unmodified 
transmission from a different part of the distributed TOE. 

J.12.3 FPT_SSP.2 Mutual trusted acknowledgement 
J.12.3.1 User application notes 

In this component, in addition to the TSF being able to provide an acknowledgement for the receipt of a data 
transmission, the TSF must comply with a request from another part of the TSF for an acknowledgement to 
the acknowledgement. 

For example, the local TSF transmits some data to a remote part of the TSF. The remote part of the TSF 
acknowledges the successful receipt of the data and requests that the sending TSF confirm that it receives 
the acknowledgement. This mechanism provides additional confidence that both parts of the TSF involved in 
the data transmission know that the transmission completed successfully. 

J.I 3 Time stamps (FPT_STM) 
J.13.1 User notes 

This family addresses requirements for a reliable time stamp function within a TOE. 

It is the responsibility of the PP/ST author to clarify the meaning of the phrase "reliable time stamp", and to 
indicate where the responsibility lies in determining the acceptance of trust, 

J.13.2 FPT_STM.1 Reliable time stamps 

J.13.2.1 User application notes 

Some possible uses of this component include providing reliable time stamps for the purposes of audit as well 
as for security attribute expiration. 

J.I 4 Inter-TSF TSF data consistency (FPT_TDC) 
J. 14.1 Usernotes 

In a distributed or composite system environment, a TOE may need to exchange TSF data (e.g. the SFP- 
attributes associated with data, audit information, identification information) with another trusted IT Product, 
This family defines the requirements for sharing and consistent interpretation of these attributes between the 
TSF of the TOE and that of a different trusted IT Product. 

The components in this family are intended to provide requirements for automated support for TSF data 
consistency when such data is transmitted between the TSF of the TOE and another trusted IT Product. It is 
also possible that wholly procedural means could be used to produce security attribute consistency but they 
are not provided for here. 

This family is different from FDP_ETC and FDPJTC, as those two families are concerned only with resolving 
the security attributes between the TSF and its import/export medium. 

If the integrity of the TSF data is of concern, requirements should be chosen from the Integrity of exported 
TSF data (FPT_ITI) family. These components specify requirements for the TSF to be able to detect or detect 
and correct modifications to TSF data in transit. 
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J.14.2 FPT_TDC.1 Inter-TSF basic TSF data consistency 

J.14.2.1 User application notes 

The TSF is responsible for maintaining thie consistency of TSF data used by or associated with the specified 
function and that are common between two or more trusted systems. For example, the TSF data of two 
different systems may have different conventions internally. For the TSF data to be used property (e.g. to 
afford the user data the same protection as within the TOE) by the receiving trusted IT product, the TOE and 
the other trusted IT product must use a pre-established protocol to exchange TSF data. 

J.I 4.2.2 Operations 

J.I 4.2.2.1 Assignment 

In FPT_TDC.1.1, the PP/ST author should define the list of TSF data types, for which the TSF shall provide 
the capability to consistently interpret, when shared between the TSF and another trusted IT product. 

In FPT_TDC.1 .2, the PP/ST should assign the list of interpretation rules to be applied by the TSF, 

J.I 5 Internal TOE TSF data replication consistency (FPT_TRC) 

J.15.1 Usernotes 

The requirements of this family are needed to ensure the consistency of TSF data when such data is 
replicated internal to the TOE. Such data may become inconsistent if an internal channel between parts of the 
TOE becomes inoperative. If the TOE is internally structured as a network of parts of the TOE, this can occur 
when parts become disabled, network connections are broken, and so on. 

The method of ensuring consistency is not specified in this component. It could be attained through a form of 
transaction logging (where appropriate transactions are "rolled t}ack" to a site upon reconnection); it could be 
updating the replicated data through a synchronisation protocol. If a particular protocol is necessary for a 
PP/ST, it can be specified through refinement. 

It may be impossible to synchronise some states, or the cost of such synchronisation may be too high. 
Examples of this situation are communication channel and encryption key revocations. Indeterminate states 
may also occur; if a specific behaviour is desired, it should be specified via refinement. 

J.15.2 FPT_,TRC.1 Internal TSF consistency 

J.1S.2.1 Operations 

J.I 5.2.1.1 Assignment 

In FPT_TRC.1.2, the PP/ST author should specify the list of SFs dependent on TSF data replication 
consistency. 

J.16 TSF self test (FPT_TST) 

J.16.1 Usernotes 

The family defines the requirements for the self-testing of the TSF with respect to some expected correct 
operation. Examples are interfaces to enforcement functions, and sample arithmetical operations on critical 
parts of the TOE. These tests can be carried out at start-up. periodically, at the request of an authorised user, 
or when other conditions are met. The actions to be taken by the TOE as the result of self testing are defined 
in other families. 

The requirements of this family are also needed to detect the cornjptton of TSF executable code (i.e. TSF 
software) and TSF data by various failures that do not necessarily stop the TOE's operation (which would be 
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handled by other families). These checks must be performed because these failures may not necessarily be 
prevented. Such failures can occur either because of unforeseen failure modes or associated oversights in the 
design of hardware, firmware, or software, or because of malicious corruption of the TSF due to inadequate 
logical and/or physical protection. 

In addition, use of this component may, with appropriate conditions, help to prevent inappropriate or damaging 
TSF changes being applied to an operational TOE as the result of maintenance activities. 

The term "correct operation of the TSF" refers primarily to the operation of the TSF software and the integrity 
of the TSF data. The abstract machine upon which the TSF software is implemented is tested via dependency 
on Underlying abstract machine test (FPT_AMT). 

J.16.2 FPT_TST.1 TSF testing 

J.I 6.2.1 User application notes 

This component provides support for the testing of the critical functions of the TSF's operation by requiring the 
ability to invoke testing functions and check the integrity of TSF data and executable code. 

J.I 6.2.2 Evaluator notes 

It is acceptable for the functions that are available to the authorised user for periodic testing to be available 
only in an off-line or maintenance mode. Controls should be in place to limit access during these modes to 
authorised users. 

J.I 6.2.3 Operations 

J.1 6.2.3.1 Selection 

In FPT_TST.1.1, the PP/ST author should specify when the TSF will execute the TSF test; during initial start- 
up, periodically during normal operation, at the request of an authorised user, at other conditions. In the case 
of the latter option, the PP/ST author should also assign what those conditions are via the following 
assignment. 

In FPT_TST.1.1, the PP/ST author should specify whether the self tests are to be carried out to demonstrate 
the correct operation of the entire TSF, or of only specified parts of TSF. 

J.16.2.3.2 Assignment 

In FPT_TST.1.1, the PP/ST author should, if selected, specify the conditions under which the self test should 
take place. 

In FPT_TST.1 .1 , the PP/ST author should, if selected, specify the list of parts of the TSF that will be subject to 
TSF self-testing. 

J.1 6.2.3.3 Selection 

In FPT_TST.1.2, the PP/ST author should specify whether data integrity is to be verified for all TSF data, or 
only for selected data. 

J.16.2.3.4 Assignment 

In FPT_TST.1.2, the PP/ST author should, if selected, specify the list of TSF data that will be verified for 
integrity. 
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Annex K 

(normative) 

Class FRU: Resource utilisation 



This class provides three families that support the availability of required resources such as processing 
capability and/or storage capacity. The family Fault Tolerance provides protection against unavailability of 
capabiiitres caused by failure of the TOE. The family Priority of Service ensures that the resources will be 
allocated to the more important or time-critical tasks, and cannot be monopolised by lower priority tasks The 
family Resource Allocation provides limits on the use of available resources, therefore preventinq users'from 
monopolising the resources. 

Figure K.1 shows the decomposition of this class into its constituent components. 



FRU FLT: Fault tolerance 



FRU_PRS: Priority of senice 



IKIH 



C 



FRURSA: Resource allocation 



Figure K.I - FRU: Resource utilisation class decomposition 
K.I Fault tolerance (FRU_FLT) 
K.1.1 User notes 

This family provides requirements for the availability of capabilities even in the case of failures Examples of 
such failures are power failure, hardware failure, or software error. In case of these errors if so specified the 
TOE will maintain the specified capabilities. The PP/ST author could specify, for example, that a TOE used in 
a nuclear plant will continue the operation of the shut-down procedure in the case of power-failure or 
communication-failure. 

Because the TOE can only continue its correct operation if the TSP is enforced, there is a requirement that the 
system must remain in a secure state after a failure. This capability Is provided by FPT FLS 1 Failure with 
preservation of secure state. ~ 

The mechanisms to provide fault tolerance could be active or passive. In case of an active mechanism 
specific functions are in place that are activated in case the error occurs. For example, a fire alarm is an active 
mechanism; the TSF will detect the fire and can take action such as switching operation to a backup In a 
passive scheme, the architecture of the TOE is capable of handling the error. For example, the use of a 
majority voting scheme with multiple processors is a passive solution; failure of one processor will not disrupt 
the operation of the TOE (although it needs to be detected to allow correction). 

For this family, it does not matter whether the failure has been initiated accidentally (such as flooding or 
unplugging the wrong device) or intentionally (such as monopolising). 

K.1.2 FRU_FLT.1 Degraded fault tolerance 

K.1.2.1 User application notes 

This component is intended to specify which capabilities the TOE will still provide after a failure of the system 
Since It would be difficult to describe all specific failures, categories of failures may be specified. Examples of 
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general failures are flooding of the computer room, short term power Interruption, breakdown of a CPU or host, 
software failure, or buffer overflow. 

K.I .2.2 Operations 

K.1 .2.2.1 Assignment 

In FRU_FLT.1 ,1 , the PP/ST author should specify the list of TOE capabilities the TOE will maintain during and 
after a specified failure. 

In FRU_FLT.1.1 . the PP/ST author should specify the list of type of failures against which the TOE has to be 
explicitly protected. If a failure in this list occurs, the TOE will be able to continue its operation. 

K.1 .3 FRU_FLT.2 Limited fault tolerance 

K. 1.3.1 User application notes 

This component is intended to specify against what type of failures the TOE must be resistant. Since it would 
be difficult to describe ail specific failures, categories of failures may be specified. Examples of general 
failures are flooding of the computer room, short term power interruption, breakdown of a CPU or host, 
software failure, or overflow of buffer. 

K.1. 3.2 Operations 

K.1. 3.2.1 Assignment 

In FRU_FLT.2.1, the PP/ST author should specify the list of type of failures against which the TOE has to be 
explicitly protected. If a failure in this list occurs, the TOE will be able to continue its operation. 

K.2 Priority of service (FRU_PRS) 

K.2.1 Usernotes 

The requirements of this family allow the TSF to control the use of resources within the TSC by users and 
subjects such that high priority activities within the TSC will always be accomplished without interference or 
delay due to low priority activities. In other words, time critical tasks will not be delayed by tasks that are less 
time critical. 

This family could be applicable to several types of resources, for example, processing capacity, and 
communication channel capacity. 

The Priority of Service mechanism might be passive or active. In a passive Priority of Service system, the 
system will select the task with the highest priority when given a choice between two waiting applications. 
While using passive Priority of Service mechanisms, when a low priority task is running, it cannot be 
interrupted by a high priority task. While using an active Priority of Service mechanisms, lower priority tasks 
might be interrupted by new high priority tasks. 

The audit requirement states that all reasons for rejection should be audited. It is left to the developer to argue 
that an operation is not rejected but delayed. 

K.2.2 FRU_PRS.1 Limited priority of service 

K.2.2.1 User application notes 

This component defines priorities for a subject, and the resources for which this priority will be used. If a 
subject attempts to take action on a resource controlled by the Priority of Service requirements, the access 
and/or time of access will be dependent on the subject's priority, the priority of the currently acting subject, 
and the priority of the subjects still in the queue. 
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K.2.2.2 Operations 
K.2.2.2.1 Assignment 

In FRU_PRS.1 .2, the PP/ST author should specify the list of controlled resources for which the TSF enforces 
priority of service (e.g. resources such as processes, disk space, memory, bandwidth). 

K.2.3 FRU_PRS.2 Full priority of service 

K.2.3.1 User application notes 

This component defines priorities for a subject. All shareable resources in the TSC will be subjected to the 
Priority of Sen/ice mechanism. If a subject attempts to take action on a shareable TSC resource, the access 
and/or time of access will be dependent on the subject's priority, the priority of the currently acting subject, 
and the priority of the subjects still in the queue. 

K.3 Resource allocation (FRU_RSA) 
K.3.1 User notes 

The requirements of this family allow the TSF to control the use of resources within the TSC by users and 
subjects such that unauthorised denial of service will not take place by means of monopolisation of resources 
by other users or subjects. 

Resource allocation rules allow the creation of quotas or other means of defining limits on the amount of 
resource space or time that may be allocated on behalf of a specific user or subjects. These rules may, for 
example: 

• Provide for object quotas that constrain the number and/or size of objects a specific user may allocate. 

• Control the allocation/deallocation of preassigned resource units where these units are under the control 
of the TSF. 

In general, these functions will be implemented through the use of attributes assigned to users and resources. 

The objective of these components is to ensure a certain amount of fairness among the users (e.g. a single 
user should not allocate all the available space) and subjects. Since resource allocation often goes beyond 
the lifespan of a subject (i.e. files often exist longer than the applications that generated them), and multiple 
instantiations of subjects by the same user should not negatively affect other users too much, the components 
allow that the allocation limits are related to the users. In some situations the resources are allocated by a 
subject (e.g. main memory or CPU cycles). In those instances the components allow that the resource 
allocation be on the level of subjects. 

This family imposes requirements on resource allocation, not on the use of the resource Itself. The audit 
requirements therefore, as stated, also apply to the allocation of the resource, not to the use of the resource. 

K.3.2 FRU_RSA.1 Maximum quotas 

K.3.2.1 User application notes 

This component provides requirements for quota mechanisms that apply to only a specified set of the 
shareable resources in the TOE. The requirements allow the quotas to be associated with a user, possibly 
assigned to groups of users or subjects as applicable to the TOE. 
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K.3.2.2 Operations 

K.3.2.2.1 Assignment 

In FRU_RSA.1.1, the PP/ST author should specify the list of controlled resources for which maximum 
resource aliocation limits are required (e.g. processes, disk space, memory, bandwidth). If all resources in the 
TSC need to be included, the words "all TSC resources" can be specified. 

K.3.2.2.2 Selection 

In FRU_RSA.1.1, the PP/ST author should select whether the maximum quotas apply to individual users, to a 
defined group of users, or subjects or any combination of these. 

In FRU_RSA.1.1, the PP/ST author should select whether the maximum quotas are applicable to any given 
time (simultaneously), or over a specific time interval. 

K.3.3 FRU_RSA.2 Minimum and maximum quotas 

K.3.3.1 User application notes 

This component provides requirements for quota mechanisms that apply to a specified set of the shareable 
resources in the TOE. The requirements allow the quotas to be associated with a user, or possibly assigned to 
groups of users as applicable to the TOE. 

K.3.3.2 Operations 

K.3.3.2.1 Assignment 

In FRU_RSA.2.1, the PP/ST author should specify the controlled resources for which maximum and minimum 
resource allocation limits are required (e.g. processes, disk space, memory, bandwidth). If all resources in the 
TSC need to be included, the words "all TSC resources" can be specified. 

K.3.3.2.2 Selection 

In FRU_RSA.2.1, the PP/ST author should select whether the maximum quotas apply to individual users, to a 
defined group of users, or subjects or any combination of these. 

In FRU_RSA.2.1, the PP/ST author should select whether the maximum quotas are applicable to any given 
time (simultaneously), or over a specific time interval. 

K.3.3.2.3 Assignment 

In FRU_RSA.2.2, the PP/ST author should spedfy the controlled resources for which a minimum allocation 
limit needs to be set (e.g. processes, disk space, memory, bandwidth).. If all resources in the TSC need to be 
included the words "ail TSC resources" can be specified. 

K.3.3.2.4 Selection 

In FRU_RSA.2.2, the PP/ST author should select whether the minimum quotas apply to individual users, to a 
defined group of users, or subjects or any combination of these. 

In FRU_RSA.2.2. the PP/ST author should select whether the minimum quotas are applicable to any given 
time (simultaneously), or over a specific time interval. 
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Annex L 

(normative) 

Class FTA: TOE access 



The establishment of a user's session typically consists of the creation of one or more subjects that perform 
operations in the TOE on behalf of the user. At the end of the session establishment procedure, provided the 
TOE access requirements are satisfied, the created subjects bear the attributes determined by the 
identification and authentication functions. This family specifies functional requirements for controlling the 
establishment of a user's session. 

A user session is defined as the period starting at the time of the identification/authentication, or if more 
appropriate, the start of an interaction between the user and the system, up to the moment that all subjects 
(resources and attributes) related to that session have been deallocated. 

Figure L.I shows the decomposition of this class into its constituent components. 



FTA_LSA; Liniitation on scope of selectable atlributes 



FTA_MC'S: Limitation on multiple concnrrent sessions 



FTA_SSL; Session locking 




FTA TAB: TOE access banners 



nA_TAH: TOE access histoiy 



FTA TSE: TOE session establishment 



Figure L.I - FTA: TOE access class decomposition 

L.1 Limitation on scope of selectable attributes (FTA_LSA) 

L.1.1 Usernotes 

This family defines requirements that will limit the session security attributes a user may select, and the 
subjects to which a user may be bound, based on: the method of access; the location or port of access; and/or 
the time (e.g. time-of-day, day-of-week). 

This family provides the capability for a PP/ST author to specify requirements for the TSF to place limits on 
the domain of an authorised user's security attributes based on an environmental condition. For example, a 
user may be allowed to establish a "secret session" during normal business hours but outside those hours the 
same user may be constrained to only establishing "unclassified sessions'. The identification of relevant 
constraints on the domain of selectable attributes can be achieved through the use of the selection operation. 
These constraints can be applied on an attribute-by-attribute basis. When there exists a need to specify 
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constraints on multiple attributes this component will have to be repiicated for each attribute. Examples of 
attributes that could be used to limit the session security attributes are: 

a) The method of access can be used to specify in which type of environment the user will be operating (e.g. 
file transfer protocol, terminal, vtam). 

b) The location of access can be used to constrain the domain of a user's selectable attributes based on a 
user's location or port of access. This capability is of particular use in environments where dial-up 
facilities or network facilities are available. 

c) The time of access can be used to constrain the domain of a user's selectable attributes. For example, 
ranges may be based upon time-of-day, day-of-week, or calendar dates. This constraint provides some 
operational protection against user actions that could occur at a time where proper monitoring or where 
proper procedural measures may not be in place. 

L.1.2 FTA_LSA.1 Limitation on scope of selectable attributes 

L.I. 2.1 Operations 

L.1. 2.1.1 Assignment 

In FTA_LSA.1.1, the PP/ST author should specify the set of session security attributes that are to be 
constrained. Examples of these session security attributes are user clearance level, integrity level and roles. 

In FTA_LSA.1.1, the PP/ST author should specify the set of attributes that can be use to determine the scope 
of the session security attributes. Examples of such attributes are user identity, originating location, time of 
access, and method of access. 

L.2 Limitation on multiple concurrent sessions (FTA_I\/ICS) 

L.2.1 User notes 

This family defines how many sessions a user may have at the same time {concurrent sessions). This number 
of concurrent sessions can either be set for a group of users or for each individual user. 

L.2.2 FTA_MCS.1 Basic limitation on multiple concurrent sessions 

L2.2.1 User application notes 

This component allows the system to limit the number of sessions in order to effectively use the resources of 
the TOE. 

L2.2.2 Operations 

L.2.2.2.1 Assignment 

In FTA_MCS.1.2, the PP/ST author should specify the default number of maximum concurrent sessions to be 
used. 

L.2.3 FTA_MCS.2 Per user attribute limitation on multiple concurrent sessions 
L.2.3.1 User application notes 

This component provides additional capabilities over those of FTA_MCS.1 Basic limitation on multiple 
concurrent sessions, by allowing further constraints to be placed on the number of concurrent sessions that 
users are able to invoke. These constraints are in terms of a user's security attributes, such as a user's 
identity, or membership of a role. 
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L.2.3.2 Operations 

L.2.3.2.1 Assignment 

In FTA_MCS.2.1, the PP/ST author should specify the rules that determine the maximum number of 
concurrent sessions. An example of a rule is "maximum number of concurrent sessions is one if the user has 
a classification level of "secret" and five otherwise". 

In FTA_MCS.2.2. the PP/ST author should specify the default number of maximum concurrent sessions to be 
used. 

L.3 Session locking (FTA_SSL) 

L.3.1 User notes 

This family defines requirements for the TSF to provide the capability for loclcing and unlocking of interactive 
sessions (e.g. keyboard locking). 

When a user is directly interacting with subjects in the TOE (interactive session), the user's terminal is 
vulnerable if left unattended. This family provides requirements for the TSF to disable (lock) the tenninal or 
terminate the session after a specified period of inactivity, and for the user to initiate the disabling (locking) of 
the temninal. To reactivate the terminal, an event specified by the PP/ST author, such as the user re- 
authentication must occur. 

A user is considered inactive, if he/she has not provided any stimulus to the TOE for a period of time. 

A PP/ST author should consider whether FTP_TRP.1 Trusted path should be included. In that case, the 
function "session locking" should be included in the operation in FTP_TRP.1 Trusted path. 

L.3.2 FTA_SSL.1 TSF-lnitiated session locking 

L.3.2.1 User application notes 

FTA_SSL.1 TSF-initiated session locking, provides the capability for the TSF to lock an active user session 
after a specified period of time. Locking a terminal would prevent any further interaction with an existing active 
session through the use of the locked terminal. 

If display devices are ovenviitten, the replacement contents need not be static (i.e. "screen savers* are 
permitted). 

This component allows the PP/ST author to specify what events will unlock the session. These events may be 
related to the tenninal (e.g. fixed set of keystrokes to unlock the session), the user (e.g. reauthenttoatkin). or 
time. 

L.3.2.2 Operations 

L.3.2.2.1 Assignment 

In FTA_SSL.1.1, the PP/ST author should specify the interval of user inactivity that will trigger the locking of 
an interactive session. If so desired the PP/ST author could, through the assignment, specify that the time 
interval is left to the authorised administrator or the user. The management functions in the FMT dass can 
specify the capabil'rty to modify this time interval, making it the defauK value. 

In FTA_SSL.1.2, the PP/ST author should specify the event(s) that should occur before the session is 
unlocked. Examples of such an event are: "user re-authenticatton" or "user enters unlock key-sequence". 
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L.3.3 FTA_SSL.2 User-initiated locking 

L.3.3.1 User application notes 

FTA_SSL.2 User-initiated locking, provides the capability for an authorised user to lock and unlock his/her 
own terminal. This would provide authorised users with the ability to effectively block further use of their active 
sessions without having to terminate the active session. 

If devices are overwritten, the replacement contents need not be static (i.e. "screen savers" are permitted). 

L3.3.2 Operations 

L3.3.2.1 Assignment 

In FTA_SSL.2.2, the PP/ST author should specify the event(s) that should occur before the session is 
unlocked. Examples of such an event are: "user re-authentication", or "user enters unlock key-sequence". 

L.3.4 FTA_SSL.3 TSF-initiated termination 

L.3.4.1 User application notes 

FTA_SSL.3 TSF-initiated termination, requires that the TSF terminate an Interactive user session after a 
period of inactivity. 

The PP/ST author should be aware that a session may continue after the user terminated his/her activity, for 
example, background processing. This requirement would terminate this background subject after a period of 
inactivity of the user without regard to the status of the subject. 

L.3.4.2 Operations 

L.3.4.2.1 Assignment 

In FTA_SSL.3.1, the PP/ST author should specify the interval of user inactivity that will trigger the tennination 
of an interactive session. If so desired, the PP/ST author could, through the assignment, specify that the 
interval is left to the authorised administrator or the user. The management functions in the FMT class can 
specify the capability to modify this time interval, making it the default value. 

L.4 TOE access banners (FTA_TAB) 

L.4.1 User notes 

Prior to identification and authentication, TOE access requirements provide the ability for the TOE to display 
an advisory warning message to potential users pertaining to appropriate use of the TOE. 

L.4.2 FTA„TAB.1 Default TOE access banners 

L.4.2.1 User application notes 

This component requires that there is an advisory warning regarding the unauthorised use of the TOE. A 
PP/ST author could refine the requirement to include a default banner. 

L.5 TOE access history (FTA_TAH) 

L.5.1 User notes 

This family defines requirements for the TSF to display to users, upon successful session establishment to the 
TOE, a history of unsuccessful attempts to access the account. This history may include the date, time, 



223 



IS 14990 (Part 2) : 2006 
ISO/IEC 15408-2 : 2005 

means of access, and port of the last successful access to the TOE, as well as the number of unsuccessful 
attempts to access the TOE since the last successful access by the identified user. 

L.5.2 FTA_TAH.1 TOE access history 

L.5.2.1 User application notes 

This family can provide authorised users with information that may indicate the possible misuse of their user 
account. 

This component request that the user is presented with the information. The user should be able to review the 
information, but is not forced to do so. If a user so desires he might, for example, create scripts that ignore this 
information and start other processes. 

L.5.2.2 Operations 

L.5.2.2.1 Selection 

In FTA_TAH.1.1, the PP/ST author should select the security attributes of the last successful session 
establishment that will be shown at the user interface. The items are; date, time, method of access (such as 
ftp), and/or location (e.g. terminal 50). 

In FTA_TAH.1.2, the PP/ST author should select the security attributes of the last unsuccessful session 
establishment that will be shown at the user interface. The items are: date, time, method of access (such as 
ftp), and/or location (e.g. terminal 50). 

L.6 TOE session establishment (FTA_TSE) 

L.6.1 User notes 

This family defines requirements to deny an user permission to establish a session with the TOE based on 
attributes such as the location or port of access, the user's security attribute (e.g. identity, clearance level, 
integrity level, membership in a role), ranges of time (e.g. time-of-day, day-of-week, calendar dates) or 
combinations of parameters. 

This family provides the capability for the PP/ST author to specify requirements for the TOE to place 
constraints on the ability of an authorised user to establish a session with the TOE. The identification of 
relevant constraints can be achieved through the use of the selection operation. Examples of attributes that 
could be used to specify the session establishment constraints are: 

a) The location of access can be used to constrain the ability of a user to establish an active session with 
the TOE, based on the user's location or port of access. This capability is of particular use in 
environments where dial-up facilities or network facilities are available. 

b) The user's security attributes can be used to place constraints on the ability of a user to establish an 
active session with the TOE. For example, these attributes would provide the capability to deny session 
establishment based on any of the following: 

• a user's identity; 

• a user's clearance level; 

• a user's integrity level; and 

• a user's membership in a role. 

This capability is particularly relevant in situations where authorisation or login may take place at a different 
location from where TOE access checks are performed. 
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c) The time of access can be used to constrain the ability of a user to establish an active session with the 
TOE based on ranges of time. For example, ranges may be based upon time-of-day, day-of-week, or 
calendar dates. This constraint provides some operational protection against actions that could occur at a 
time where proper monitoring or where proper procedural measures may not be in place. 

L.6.2 FTAjrSE.i TOE session establishment 

L.6.2.i Operations 

L.6.2.1.1 Assignment 

In FTA_TSE.1.1, the PP/ST author should specify the attributes that can be used to restrict the session 
establishment. Example of possible attributes are user identity, originating location (e.g. no remote temiinals). 
time of access (e.g. outside hours), or method of access (e.g. X-windows), 
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Annex M 

(normative) 

Class FTP: Trusted path/channels 



Users often need to perform functions through direct interaction with the TSF. A trusted path provides 
confidence that a user is communicating directly with the TSF whenever it is involved. A user's response via 
the trusted path guarantees that untrusted applications cannot intercept or modify the user's response 
Similarly, trusted channels are one approach for secure communication between the TSF and remote IT 
products. 

Figure 2 of this part of ISO/IEC 15408 illustrates the relationships between the various types of 
communication that may occur within a TOE or network of TOEs (i.e. Internal TOE transfers Inter-TSF 
transfers, and import/Export Outside of TSF Control) and the various forms of trusted paths and channels. 

Absence of a trusted path may allow breaches of accountability or access control in environments where 
untrusted applications are used. These applications can intercept user-private information, such as passwords 
and use it to impersonate other users. As a consequence,, responsibility for any system actions cannot be' 
reliably assigned to an accountable entity. Also, these applications could output erroneous information on an 
unsuspecting user's display, resulting in subsequent user actions that may be erroneous and mav lead to a 
security breach. ' 

Figure M.1 shows the decomposition of this class into its constituent components. 



FTP rrC: luter-TSF tnisted channel 



FTP TRP: Tnisted path 



Figure M.1 - FTP: Trusted path/channels class decomposition 

M.1 Inter-TSF trusted channel (FTPJTC) 

M.1.1 User notes 

This family defines the rules for the creation of a trusted channel connection that goes between the TSF and 
another trusted IT product for the performance of security critical operations between the products An 
example of such a security critical operation is the updating of the TSF authentication database by the transfer 
of data from a trusted product whose function is the collection of audit data. 

M.1.2 FTPJTd Inter-TSF trusted channel 
M.1 .^.1 User application notes 

This component should be used when a trusted communication channel between the TSF and another trusted 
IT product is required. 

M.1. 2.2 Operations 

IVI.1. 2.2.1 Selection 

In FTPJTC. 1,2, the PP/ST author must specify whether the local TSF, the remote trusted IT product or both 
shall have the capability to initiate the trusted channel. 
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M.I. 2.2.2 Assignment 



In FTP_ITC.1.3, the PP/ST author should specify the functions for which a trusted channel is required. 
Examples of these functions may Include transfer of user, subject, and/or object security attributes and 
ensuring consistency of TSF data. 

M.2 Trusted path (FTP_TRP) 
M.2.1 User notes 

This family defines the requirements to establish and maintain trusted communication to or from users and the 
TSF. A trusted path may be required for any security-relevant interaction. Trusted path exchanges may be 
initiated by a user during an interaction with the TSF, or the TSF may establish communication with the user 
via a trusted path. 

M.2.2 FTP_TRP.1 Trusted path 

M.2.2.1 User application notes 

This component should be used when trusted communication between a user and the TSF is required, either 
for initial authentication purposes only or for additional specified user operations. 

M.2.2.2 Operations 

M.2.2.2.1 Selection 

In FTP_TRP.1.1, the PP/ST author should specify whether the trusted path must be extended to remote 
and/or local users. 

In FTP_TRP.1.2, the PP/ST author should specify whether the TSF. local users, and/or remote users should 
be able to initiate the trusted path. 

In FTP_TRP.1.3. the PP/ST author should specify whether the trusted path is to be used for initial user 
authentication and/or for other specified services. 

M.2.2.2.2 Assignment 

in FTP_TRP.1 .3, if selected, the PP/ST author should Identify other services for which trusted path is required, 
if any. 



227 



Bureau of Iridian Standards 

BIS is a statutory institution established under the Bureau of Indian Standards Act, 1986 to promote 
harmonious development of the activities of standardization, marking and quality certification of goods 
and attending to connected matters in the country. 

Copyright 

BIS has the copyright of all its publications. No part of these publications may be reproduced in any form 
without the prior permission in wrting of BIS. This does not preclude the free use, in the course of 
implementing the standard, of necessary details, such as symbols and sizes, type or grade designations. 
Enquiries relating to copyright be addressed to the Director (Publications), BIS. 

Review of Indian Standards 

Amendments are issued to standards as the need arises on the basis of comments. Standards are also 
reviewed periodically; a standard along with amendments is reaffirmed when such review indicates that 
no changes are needed; if the revsew indicates that changes are needed, it is taken up for revision. 
Users of Indian Standards should ascertain that they are in possession of the latest amendments or 
edition by referring to the latest issue of 'BIS Catalogue' and 'Standards : Monthly Additions'. 

This Indian Standard has been developed from Doc : No. LTD 38 (2051 ). 



Amendments Issued Since Publication 



Amend No. 



Date of Issue 



Text Affected 



BUREAU OF INDIAN STANDARDS 



Headquarters : 



Manak Bhavan, 9 Bahadur Shah Zafar Marg, New Delhi 1 10 002 
Telephones : 2323 01 31, 2323 33 75, 2323 94 02 

Regional Offices : 

Central : Manak Bhavan, 9 Bahadur Shah Zafar Marg 
NEW DELHI 110 002 

Eastern : 1/14 C.LT. Scheme VII M, V. I. P. Road, Kankurgachi 
KOLKATA 700 054 

Northern : SCO 335-336, Sector 34-A, CHANDIGARH 160 022 
Southern : C.IT. Campus, IV Cross Road, CHENNAI 600 1 13 



Western 



Branches 



Manakalaya, E9 MIDC, Marol, Andheri (East) 
MUMBAI 400 093 



Telegrams : Manaksanstha 
(Common to all offices) 



{ 



Telephone 

2323 76 17 
2323 38 41 



r2337 84 99, 2337 85 61' 
12337 86 26,2337 9120 

f 260 38 43 
1 260 92 85 

f2254 12 16, 2254 14 42 
\2254 25 19,2254 23 15 

f 2832 92 95, 2832 78 58 
12832 78 91,2832 78 92 



: AHMEDABAD, BANGALORE. BHOPAL. BHUBANESHWAR. COIMBATORE. FARIDABAD. 
GHAZIABAD. GUWAHATI. HYDERABAD. JAIPUR. KANPUR. LUCKNOW. NAGPUR. 
NALAGARH. PATNA. PUNE. RAJKOT. THIRUVANANTHAPURAM. VISAKHAPATNAM. 



Printed at Prabhat Offset Press, New Delhi-2 



